Modern XMPP project discussion - 2024-06-19

Sometimes I feel like it'd be cool if XMPP didn't encode binary data as base64

Sometimes we all have that feeling

But then you would ask yourself for the alternative?

What if we adopted a binary XML representation e.g. EXI so this could be made possible?

EXI is nice in theory, but it gets icky past that unfortunately

How so?

IIRC open-source implementations are scarce, for example

And to make the most of it you need to use it in schema mode, which would require a lot of effort

couldnt we just do it all of it over eris? but then that would require ecosystem buy-in /thinking

And what if you just use it so you don't need to use base64 anymore?

Or does EXI require schemas?

No, I think EXI can be used without schemas. But then basically the only gain is not using base64, and it's a lot of work for that small improvement.

Just imagine how much bytes you will save in total across the XMPP network if everyone used EXI and sending binary data over the XML stream were actually supported :o ✏

Probably less than a 5-minute YouTube video per day :)

Maybe it won't save as much data as actually implementing proper multicasting would, idk :P

How stringent have most clients been with being XML namespace-aware, or is most of it just very lax parsers?

I think all the successful clients do it properly. Namespace-aware APIs are not too hard to find.

I guess I'll put in the modicum of effort to make it namespace-aware then. Meanwhile, for connection states, would it be fair to summarize things down to: - dead (no connection yet, or TCP connection closed), - preauth (connection open, not fully authenticated yet) - prebind (authenticated, but not bound to a resource ID yet) - ready (authenticated, bind complete, ready to send/receive traffic) - closing (gracefully going offline, or closing per stream error) Or is there something else worth including? Would CSI (XEP-0352) change anything, or be worth of some additional connection state (sleep?)?