-
emus
https://fosdem.org/2023/news/2022-12-08-accepted-stands-fosdem-2023/
-
emus
Guus: btw were there any attempts on the hoodies again?
-
ralphm
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.
-
Zash
Yes! Moar SWAG!
-
mathieui
My 10 years old xmpp <presence> shirt is quite worn out too đ
-
root
Someone said swag??!
-
Zash
Aren't we way overdue for zombie themed swag? :)
-
Guus
ugh, I totally forgot about that.
-
Guus
it's one of those many things on the to-do list.
-
Peter Waher
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?)
-
Zash
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.
-
Zash
and "about as long as archives" defaulting to a week
-
Menel
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
-
Zash
Guus, swag zombiesâ˝
-
Zash
When's the Summit? (2 days before as usual?)
-
Daniel
There is a summit?
-
Zash
To Summit or not to Summit, that is the question. đď¸
-
Guus
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.
-
Peter Waher
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?)
-
Zash
Peter Waher, deletion? I'd probably prototype with an ad-hoc command if I was doing it.
-
Peter Waher
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)
-
Guus
Peter: no argument there.
-
Zash
My unscientific observation is that 90% of the downloads happens within seconds of the upload.
-
Peter Waher
Zash: Wouldnât a HTTP DELETE method be more appropriate for manual removal? I mean, we already use HTTP GET and PUTâŚ
-
Peter Waher
Zash: Yes, for file transfer, this seems logical, if both are connected at the same time.
-
Guus
access control might be tricky.
-
Guus
or auth, rather.
-
Peter Waher
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.
-
Zash
Include a `<header name=Authorization deletion-token</header>`, it would work
-
Zash
Peter Waher, ad-hoc command could include listing your uploads (if that info is kept)
-
Daniel
> 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'
-
Daniel
Which is the default already
-
Zash
Daniel, do you still want an 'infinite' for use with avatars?
-
Zash
OTOH, expiring avatars might be a handy privacy feature
-
Peter Waher
Daniel: It is a request. It provides information to the server. And the server can respond with its decision
-
Daniel
Zash: yes kinda. But that's complicated because you want the old slot to be overwritten
-
Peter Waher
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
-
Daniel
Or you don't want infinite but until I upload the next
-
Daniel
I'm kinda thinking avatar should be solved differently
-
jonasâ
reusable slots?
-
Peter Waher
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
-
Daniel
Http upload could be a reused mechanism. But it would be a seperate node (that also handles pep node creation and resizing)
-
Zash
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)
-
Daniel
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
-
singpolyma
I added http uploaded 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✎ -
singpolyma
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 ✏
-
Zash
Daniel, are multiple formats used by anyone other than me?
-
Trung
I demand 8K avatar !
-
Daniel
Zash: yes we do
-
Daniel
We upload heif and webp
-
Zash
where? since when?
-
Daniel
Older versions of Android don't do heif. But it's much smaller files
-
Andrzej
Zash, Siskin IM and Beagle IM are also using multiple avatar formats
-
Zash
My own node has over-optimized PNG + larger JPEG fwiw
-
Daniel
And then the receiving client can pick and choose
-
Daniel
Zash: a commercial project I'm consulting for
-
Zash
in Conversations when? :)
-
Daniel
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
-
Daniel
But for a proper solution I would like to do the upload bits via xmpp as well
-
Zash
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.
-
Daniel
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
-
Daniel
For more fun you could probably also jingle ft your full size avatar to said domain
-
Zash
Upload service that supports re-encoding to other formats/sizes would be nice to standardize. Not very privacy-friendly tho...
-
singpolyma
> For more fun you could probably also jingle ft your full size avatar to said domain Now you're speaking my language
-
Zash
HTTP upload but with XEP-0065 is a thing I've thought about... didn't Link Mauve even do such a thing?
-
Daniel
Well technically avatar.domain.tld could handle many different ways of uploading. But the more you offer the harder it gets for the server
-
Daniel
Clients already have jingle ft code but I'm not sure servers want to implement jingle ft
-
singpolyma
Daniel: why not? It's super simple for a server. Way easier than for a client
-
Daniel
Dunno. Jingle is hard đ¤ˇââď¸
-
Daniel
Not the socks5 server bits
-
Daniel
But the state holding and stuff
-
Daniel
But like I said I'm generally open to having the server support multiple ways to upload
-
Zash
Anyone remember Jingle Nodes?
-
Daniel
I actually don't. But now I'm curious
-
singpolyma
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
-
Daniel
I guess...
-
Daniel
but then you have to consider web clients
-
Daniel
and either do webrtc datachannels or 0370
-
Peter Waher
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.
-
singpolyma
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?
-
Daniel
Sctp I think
-
Daniel
But I don't have any first hand experience with that yet
-
moparisthebest
As an aside: great to read all the new membership applications this round
-
emus
https://twitter.com/xmpp/status/1601310896101490690 https://nitter.net/xmpp/status/1601310896101490690#m https://fosstodon.org/@xmpp/109485571343477590