Modern XMPP project discussion - 2025-02-23

Currently, there is no stable endpoint for HTTP uploads that instructs the server to retain these sticker files. Most servers regularly delete files unless users choose to store all stickers locally and re-upload them each time they are used.

Additionally, some service providers do not understand how to set up CORS, which results in the inability to use the service on the web.

There have already been many discussions on this topic.

It's not hard to write a script to upload/host sticker files through, not every server would need to host every sticker pack (or any at all). I don't think it's a big obstacle, especially if there's interest and drive to deploy it correctly and have simple tools to test it

of everything with XMPP, it is one of _the_ specific things I want to advance

Yes, I look forward to seeing someone put this into practice.

The stickers can be completely out-of-band, it wouldn't even need to be uploaded by the XMPP client. It's just the part of creating a sticker pack and importing it in the client for the first time (before it's ever published in PubSub) that might take a little effort. But again, there could easily just be some standalone 'sticker' file host; you go to an instance of the service, authenticate if needed, upload the sticker files, write the descriptions or alternate representations for each, then export some XML blob (that's the exact same data as what would be published in PubSub) from it, and import it in the client (which would then publish that imported XML right into PubSub after validation/linting, and ta-da, you have a sticker pack you can start using ✏

I'm sure it's something that can be written in a weekend as fairly quick PHP and JavaScript, which I hopefully can get to this weekend.

arcanicanis, in your attributes vs. children example, you only gained 34 bytes out of 158, which isn’t really much.

Plus if we ever reintroduce compression of any kind, the overhead of duplicated names in the opening and closing tags will vanish.

And the very fact that nobody bothers with compression kind of hints at it being unneeded on today’s Internet.

Even when my server was behind a pretty poor ADSL connection, XMPP was the least of my worries.

It's good that we're a bit concerned about byte counts at least, in order to keep it lean 😁️

FWIW, 34/158 is 20+%, so considered *in isolation* maybe a meaningful optimisation.

34 bytes out of how many for the actual file transfer? :)

How large are your photos?

I know, hence the *in isolation* qualifier...

There are many more widespread optimisations to consider before removing 34 bytes every time a file is to be transfered.

One I want to experiment on for instance is to define a prefix for all common namespaces on the stream:stream, and then use that everywhere.

In this example this would incidentally remove 33 bytes and add at least two, so 31.

How about `<r xmlns='urn:xmpp:sm:3'/>` → `<sm:r/>`

Exactly.

> arcanicanis, in your attributes vs. children example, you only gained 34 bytes out of 158, which isn’t really much. It's still evading the core point of the argument: when is there going to be a situation where one file has more than one width/height/filesize/mediatype/filename, or need further annotation of those values? Additionally, it contradicts the pattern, as it even does those values as attributes instead for <thumbnail />, but not <file />: https://xmpp.org/extensions/xep-0447.html#example-1 ✏ ↺

arcanicanis, this was the only point I disagreed with you on, otherwise when there is no case where there can be multiple values, or different children in the future, attributes do make sense.

Alright, fair

But compatibility with existing software which are already using the current way is more important imo.

However, what is going to be critically lost in it being moved to attributes? It's _metadata_, it's not the main payload, and those values are merely _hints_, the actual values of the file when retrieved could be something else entirely, so it's not something to be depended on.

arcanicanis, compatibility with existing clients.

and 'existing software' being Psi and Psi+ as the only "full implementation"

What do you mean “full” implementation?

per self-declared implementation status listed with the XEPs on xmpp.org/extensions

further, with the XEP, those values are _RECOMMENDED_ not required, ergo, those values being absent (and moved elsewhere) wouldn't break expectations ✏

arcanicanis, I see six implementations listed there.

And no Psi.

For XEP-0447.

I had mixed up with XEP-0385 mistakenly

arcanicanis, anyway, the complete vs. partial status is meant to be augmented with a note element, where implementations can describe why they didn’t implement the entire specification.

If they don’t do that, the tag is pretty meaningless.