XSF Discussion - 2022-12-09

  1. emus


  2. emus

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

  3. 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.

  4. Zash

    Yes! Moar SWAG!

  5. mathieui

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

  6. root

    Someone said swag??!

  7. Zash

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

  8. Guus

    ugh, I totally forgot about that.

  9. Guus

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

  10. 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?)

  11. 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.

  12. Zash

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

  13. 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

  14. Zash

    Guus, swag zombies‽

  15. Zash

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

  16. Daniel

    There is a summit?

  17. Zash

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

  18. 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.

  19. 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?)

  20. Zash

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

  21. 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)

  22. Guus

    Peter: no argument there.

  23. Zash

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

  24. Peter Waher

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

  25. Peter Waher

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

  26. Guus

    access control might be tricky.

  27. Guus

    or auth, rather.

  28. 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.

  29. Zash

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

  30. Zash

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

  31. 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'

  32. Daniel

    Which is the default already

  33. Zash

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

  34. Zash

    OTOH, expiring avatars might be a handy privacy feature

  35. Peter Waher

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

  36. Daniel

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

  37. 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

  38. Daniel

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

  39. Daniel

    I'm kinda thinking avatar should be solved differently

  40. jonas’

    reusable slots?

  41. 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

  42. Daniel

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

  43. 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)

  44. 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

  45. 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

  46. 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

  47. Zash

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

  48. Trung

    I demand 8K avatar !

  49. Daniel

    Zash: yes we do

  50. Daniel

    We upload heif and webp

  51. Zash

    where? since when?

  52. Daniel

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

  53. Andrzej

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

  54. Zash

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

  55. Daniel

    And then the receiving client can pick and choose

  56. Daniel

    Zash: a commercial project I'm consulting for

  57. Zash

    in Conversations when? :)

  58. 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

  59. Daniel

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

  60. 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.

  61. 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

  62. Daniel

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

  63. Zash

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

  64. singpolyma

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

  65. Zash

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

  66. 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

  67. Daniel

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

  68. singpolyma

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

  69. Daniel

    Dunno. Jingle is hard 🤷‍♂️

  70. Daniel

    Not the socks5 server bits

  71. Daniel

    But the state holding and stuff

  72. Daniel

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

  73. Zash

    Anyone remember Jingle Nodes?

  74. Daniel

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

  75. 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

  76. Daniel

    I guess...

  77. Daniel

    but then you have to consider web clients

  78. Daniel

    and either do webrtc datachannels or 0370

  79. 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.

  80. 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?

  81. Daniel

    Sctp I think

  82. Daniel

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

  83. moparisthebest

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

  84. emus

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