XSF Discussion - 2022-12-09

https://fosdem.org/2023/news/2022-12-08-accepted-stands-fosdem-2023/

Guus: btw were there any attempts on the hoodies again?

If there's demand for new swag, I'm happy to help out with that again. Can't believe it is 4 years since we did the previous run.

Yes! Moar SWAG!

My 10 years old xmpp <presence> shirt is quite worn out too 😛

Someone said swag??!

Aren't we way overdue for zombie themed swag? :)

ugh, I totally forgot about that.

it's one of those many things on the to-do list.

Hello everyone. A short question: How have you solved life cycle management of uploaded using HTTP File upload? (I.e. for how long will the files be available on the server? How can you delete them manually?)

Peter Waher, I think keeping them about as long as archives is common. Default in e.g. Prosody. No manual deletion specified unless you (the admin) go in the underlying storage and do it.

and "about as long as archives" defaulting to a week

Peter Waher: if you use and external component for uploads a simple cron job with "find... - delete" will do the job., deleting older then x days

Guus, swag zombies‽

When's the Summit? (2 days before as usual?)

There is a summit?

To Summit or not to Summit, that is the question. 💀️

Peter: I have an implementation that will start deleting least-recently-modified files when disk space runs out. I have 0 feedback on how that's behaving in practice.

Menel: You suggest search XEP + custom delete action? (BTW: I have a proprietary solution already working, but that is hardly interoperable. If my software connects to my broker, it works; but how to do it in an interoperable manner?)

Peter Waher, deletion? I'd probably prototype with an ad-hoc command if I was doing it.

Guus: Yes. You could also base it on least used, or time since last request. (Personally, I favour the client being able to provide information about expected/desired lifetime. The server can hardly know the use case for which the file was uploaded, and there may be use cases where a short life time is acceptable, and others that prefer a longer)

Peter: no argument there.

My unscientific observation is that 90% of the downloads happens within seconds of the upload.

Zash: Wouldn’t a HTTP DELETE method be more appropriate for manual removal? I mean, we already use HTTP GET and PUT…

Zash: Yes, for file transfer, this seems logical, if both are connected at the same time.

access control might be tricky.

or auth, rather.

In a slot request, one could add expected life time, and let the client specify for how long the client desires the file to be available.

Include a `<header name=Authorization deletion-token</header>`, it would work

Peter Waher, ad-hoc command could include listing your uploads (if that info is kept)

> In a slot request, one could add expected life time, and let the client specify for how long the client desires the file to be available. It highly depends on the use case. For most IM contexts there is little incentive for a client to not choose 'max'

Which is the default already

Daniel, do you still want an 'infinite' for use with avatars?

OTOH, expiring avatars might be a handy privacy feature

Daniel: It is a request. It provides information to the server. And the server can respond with its decision

Zash: yes kinda. But that's complicated because you want the old slot to be overwritten

And yes, there’s a lot of incentives for clients to provide the correct expected life time: GDPR. I.e. all personal information must already be assigned a life time

Or you don't want infinite but until I upload the next

I'm kinda thinking avatar should be solved differently

reusable slots?

And so, it removes the problem from the client developer, if they can specify for how long the information is stored, and have the server delete it

Http upload could be a reused mechanism. But it would be a seperate node (that also handles pep node creation and resizing)

Avatar PEP thing seems good enough for now, and if you squint at it just right, you can upload multiple resolutions and formats (I did, for the lulz)

Yes pep avatars are good. We also use multi res and multi format. But how does the avatar get into the pep node is something we could improve upon

I added http upload to my server for the first time this year in order to get infinite retention for a certain private MUC, but I use external storage module for that anyway ✏

Daniel, are multiple formats used by anyone other than me?

I demand 8K avatar !

Zash: yes we do

We upload heif and webp

where? since when?

Older versions of Android don't do heif. But it's much smaller files

Zash, Siskin IM and Beagle IM are also using multiple avatar formats

My own node has over-optimized PNG + larger JPEG fwiw

And then the receiving client can pick and choose

Zash: a commercial project I'm consulting for

in Conversations when? :)

When I solved the upload problem in a nice way. The project I'm talking About does upload and reencoding out of band. And then it's vanilla pep/xmpp from there

But for a proper solution I would like to do the upload bits via xmpp as well

And XEP-0084 does already have provisions for pointing at an URL. Probably fine if your 8K avatar uploaded somewhere expires if your smaller in-band one stays.

The rough idea is that you have avatar.domain.tld from that you can http slot request a url. You upload one full size avatar to it. 'avatar.domain.tld' handles re-encoding and populating the existing pep node

For more fun you could probably also jingle ft your full size avatar to said domain

Upload service that supports re-encoding to other formats/sizes would be nice to standardize. Not very privacy-friendly tho...

> For more fun you could probably also jingle ft your full size avatar to said domain Now you're speaking my language

HTTP upload but with XEP-0065 is a thing I've thought about... didn't Link Mauve even do such a thing?

Well technically avatar.domain.tld could handle many different ways of uploading. But the more you offer the harder it gets for the server

Clients already have jingle ft code but I'm not sure servers want to implement jingle ft

Daniel: why not? It's super simple for a server. Way easier than for a client

Dunno. Jingle is hard 🤷‍♂️

Not the socks5 server bits

But the state holding and stuff

But like I said I'm generally open to having the server support multiple ways to upload

Anyone remember Jingle Nodes?

I actually don't. But now I'm curious

Most of the complexity is negotiating a candidate, but for me in a server component I just don't do that part. I have a public ip so I force to always use that

I guess...

but then you have to consider web clients

and either do webrtc datachannels or 0370

For multi-resolution images (or video) over XMPP I personally use the browser’s ability to select candidate, coupled with the httpx URI scheme defined in XEP-0332 and avoid the file upload altogether.

Daniel: right, web client can't do socks5 so I guess it would fall back to IBB, which isn't ideal but works. WebRTC can't do real ICE-TCP can it?

Sctp I think

But I don't have any first hand experience with that yet

As an aside: great to read all the new membership applications this round

https://twitter.com/xmpp/status/1601310896101490690 https://nitter.net/xmpp/status/1601310896101490690#m https://fosstodon.org/@xmpp/109485571343477590