Modern XMPP project discussion - 2025-02-22

had this thought in the morning about the concept of stickers in chats. Wouldn’t it be more efficient to negotiate between clients about which stickers we have instead of sending a full image/gif every time? Like just sending something like :nice_meme, and then the client would display the appropriate image? Alternatively, when updating a sticker pack version, it could just download the missing files

or even simpler - instead of sending the file every time, just check if it's already on the server and then use it normally with HTTP upload

Thats how it's done already

edhelas: really? how is it implemented

> edhelas: really? how is it implemented https://xmpp.org/extensions/xep-0231.html ↺

Oh yeah was about to say that's how BoB works

I still disagree with BoB as a solution for stickers, given it was probably envisioned back in the context of emoticons that were probably barely 32x32 pixels or so; meanwhile trying to stuff high-quality high-resolution stickers that get further overhead being encoded as base64 to fit within one single stanza, is something that feels error-prone and the lower threshold for max stanza size is probably going to stay as 65kb (ejabberd's default), which with base64 overhead means you have effectively an upper limit of 43.9kb to sticker size, or else face complications with the server forcibly dropping the connection (if I remember correctly) whenever you push out an oversized stanza. Even with butchering some Telegram stickers with heavy WebP compression, it's still often a valley until something fits under <43kb.

I'm aware Movim does stickers via BoB as a distribution method with images that are typically ~200x200 (or higher, with much heavier compression), but it's hard to sell "hey, you have to butcher your resolution and/or quality, and gl;hf in ever expecting anything that comes out clean and high-res for a HiDPI screen" to artists

and also know of it using BoB, per diagnosing why Movim went into a constant re-connection loop when adding custom stickers that were over the stanza limit, whenever an oversized sticker was sent ✏

Well, you have to optimize your stickers

There's no magic there

300x300 optimized PNG is between 15 and 30ko

+30% base64, I think we can live with it

My argument is that it's probably worth out-of-band, rather than (ab)using XMPP as a large binary blob transport

I'm open to get a new XEP, but that one is "good enough" for me 🤷‍♂️

And if you have a low size limitation like that for stickers, I don't think you'll receive a lot of avatars as well, that are often above that limit

Yes, I understand it's a fair option, especially as something that doesn't take any special server support or anything to implement

https://xmpp.org/extensions/xep-0385.html and https://xmpp.org/extensions/xep-0447.html allow carrying a hash of the file, that should allow checking a local cache or sticker storage, no?

I've seen those XEPs, not sure if there's a way it could be more concisely done as it's probably a little verbose. Meanwhile, one missing part is probably a 'media proxy' XEP, because the counterargument can also become 'what if the sticker is used to semi-de-anonymize the recipients?'

When I finish my other projects I do want to dork around with XEP-0447/XEP-0449

whereas a 'media proxy' could be an optional service advertised by a server, presented as an HTTPS endpoint that a client could use for cacheable proxied media access to XEP-0363 HTTP File Uploads or other HTTP-based out-of-band transports

Is there no way to do BoB or stickers over HTTP?

On Conversations and forks, using HTTP upload seems pretty close to being appropriate for stickers UI-wise

BoB exists because you can't push raw binary over an XMPP stream, it creates a mechanism to wrap binary blobs in base64 to make it transportable in an XML payload, but the other thing is that BoB isn't really 'packetized' and the whole payload has to fit in one stanza. Meanwhile, "Stateless file sharing" and some others _would_ be an option to have stickers retrieved over HTTPS instead, but I'm unaware of any active implementations ✏

Well sharing an image has the same UI as a sticker on most clients that auto-download

and the problem with plain HTTP File Uploads is that it's redundant, the files (on most servers) eventually expire and rotate out, no deduplication; ergo, some method to 'publish' a sticker pack and where to retrieve it, and a mode of referencing it, would be the best of every option

So then you can use HTTP upload, stateless file sharing, etc.

whereas last I peeked at XEP-0449 as proposed; it's publishing a sticker pack via PubSub, and then referencing it via Stateless file sharing, with the addition of what pack it's from (...which feels a little redundant, and I don't see what value it's adding, other than making the broader collection discoverable)

on the XEP list on xmpp.org, is 'implementation status' of a XEP for a specific client just a self-proclaimed, or does anyone actually go through and test that?

Self-claimed, by adding an entry in a file that goes into the website build.

Users test it. :)

e.g. there allegedly being 6 client implementations for SIMS with Psi/Psi+ proclaimed as fully implemented, yet I can't find any hints or clues of it being implemented in Psi (in just a cursory review)

https://github.com/psi-im/iris/blob/eb691eba9584ab51fb016fcf3b643c317ff5bd7e/src/xmpp/xmpp-im/xmpp_reference.cpp#L26 looks like there's some code that mentions the XEP namespace at least

That is always a neat thing with XMPP though: being able to Ctrl+F for the namespace, to quickly find the hints of where support for a XEP might start at

as a nitpick with XEP-0447, wouldn't it have been fairer to have width, height, size, type, name as attributes instead, given there's generally not going to be multiple dimensions/sizes/etc for one file (rather than doubling the bytes needed to serialize that info)?

the difference between: ``` <file xmlns='urn:xmpp:file:metadata:0' name='summit.jpg' size='3032449' width='4096' height='2160' mediatype='image/jpeg'> ``` and ``` <file xmlns='urn:xmpp:file:metadata:0'><name>summit.jpg</name><size>3032449</size><width>4096</width><height>2160</height><media-type>image/jpeg</media-type> ```

(or probably a ping to larma, as I believe they're the author and present here?)

arcanicanis, well, that surely is possible, but it also has downsides (e.g. makes extensibility harder or non-canoncical)

I'm not sure there are good general XML design documents somewhere, but generally, I'd put things on attributes that are metadata to what is in the childs

When is there a situation that there's multiple sizes/dimensions to a single file, or where that data would need further annotation? Because it feels like it's planning for a hypothetical future circumstance that might not exist.

well, have you seen the examples with hashes and thumbnails?

my understanding has generally been: if there's a situation where something may have multiple occurances, then it absolutely should be an element; if it's strictly singular and generally meta, it could pass as an attribute

Yes, that's why I did not mention hashes, because that is an appropriate case

but semantically, width/height/size/mediatype are a similar kind of metadata as hash, so it would be weird to position them differently

It still circles back to the original argument: when is a single file going to have different file sizes or dimensions, or need alternate representations of those facts

I understand that it would be smaller in bytes, but that alone should not be the main decision maker. And consistency with other metadata like hash for me is more important than saving a few bytes (especially when those are just due to the chosen serializatio)

If you worry about size in bytes, use EXI, they said.

Yes, but again, those are very different things; hash algorithms are typically temporary as over time things get changed out; meanwhile file size represented in byte count, and image size in pixels has been very timeless

Technically the XEP somewhat contradicts with itself: you have size/width/height as child elements for <file>, but then as attributes for <thumbnail> ✏

Technically the XEP somewhat contradicts with itself: you have size/width/height as child elements for <file>, but then as attributes when represented in <thumbnail> ✏