[rafaelcosta]

There's a reason why this went from widely supported/used to... not so much. And even if most people claim it's big-co's locking down their ecosystems (which is partly true), the "extensibility" of XMPP allows for a very convoluted ecosystem with some servers supporting certain XEP and some not. Also, sorry, but XML just sucks to work with nowadays :(

[forty]

If only it was XML. It's actually something based on a subset of XML for which there were enough constraints than in practice you almost had to write custom parser. XMPP would have been a much nicer protocol if each stanza were independent XML documents IMO.

[mickael]

You need a stream parser like expat. No need to code your custom parser and once you settle at level n+1 in the XML it is just like parsing independent document. But again, the parsing is hidden by existing XMPP library, so you do not even need to go to that level of details.

[forty]

I meant for implementing the protocol of course. If you don't have to implement it, then of course it does not matter as much if it's bad or not.

At the time I was looking into it closely, there were issues with XML, like with the starttls messing the original document, there were issues with XML validation (for xml namespaces I think?), and other minors arrangements with the XML spec such that using a normal pull parsing lib was not enough to solve all problems. But it was quite a long time ago (10+ years), possibly that have been solved for a while.

[forty]

in term of practical impact of using XML like this, at the time, the server has to practically parse everything that was in the content of messages not addressed to the server itself. I would imagine a reasonable protocol should separate addressing from the content in such a way that the router doesn't have to parse all the content to do its job

[the_third_wave]

Certainly XMPP is not perfect but then again, nothing is. The extensibility does make it a bit of a gamble whether any specific server - which can be used for all kinds of purposes, many of which not related to human communication - offers everything a client program expects it to. Then again if your communication/discussion partners all make sure to use servers which support the essentials for the type of use you want to make of it - usually that'll mean those XEPs need for OMEMO, muc and maybe Jingle, the Conversations project publishes a list of what is needed [1] - things work just fine and you'll be communicating without the need for centralised (monetised, censored, monitored, ...) services. I've been running it for decades now, first as a backup "just in case" communication channel but for the last 7 years or so as my main channel to family and friends. We're using mostly the Conversations (-derived) client(s) on mobile, Gajim on desktop and Converse.js on web with servers running on different types of hardware ranging from SBCs (RasPi etc) to ex-lease enterprise hardware. The maintenance burden on the server software is close to zero with Prosody, it hardly takes any resources and has never crashed on me.

[1] https://codeberg.org/inputmice/Conversations#xmpp-features

[throwaway915]

No one hand codes JSON. No one hand codes XML. It's much of a muchness.

[GoblinSlayer]

Isn't e2ee an optional extension in matrix?