For instance, it works as a constant, uninterrupted stream. You never close the document until the disconnection. Which means you absolutely have to parse it with a stream parser.
It could have been something sensible, like a document per message: "Here's 300 characters of XML document: <xml>....". But nope.
And what's up with this? https://xmpp.org/extensions/xep-0394.html
That made me remember IBM JSONx... https://www.ibm.com/docs/en/datapower-gateway/10.6.x?topic=2...
Are there more elegant or natural ways to do it? Probably. But when you say ‘extremely complex’, saying ‘codepoints 7 to 15 should be bold’ is not what comes to my mind.
* It's not standard. You can't plug in some normal formatting library there and be done with it.
* You'll probably end up having to write conversions back and forth.
* It's fragile -- if anything gets misaligned it'll break
* It's tooling unfriendly. Think things like Nagios, Grafana, etc sending formatted notifications. Everything can do this or <b>this</b>, but practically nothing is set up to accommodate this format.
* It leaks into other subsystems. You can't eg, just search/replace/insert/delete words if you need to for any reason without breaking this.
Is it the worst thing ever? No, but it seems to go with the pattern that nothing in XMPP is normal or comfortable. Everything has this weird particular flavor to it and more complexity than necessary.
If it were up to me, my option would be to support 2 things: Markdown for simple cases, and embedded HTML for when you really have to get fancy. Each of those can be handed out to existing code and you don't ever have to keep adding extensions because what if people want colors or something now.
And you could use markdown. Just get the rendered spanned text result and transpile it. This would be true for any editor as well, just get convert it to spanned text, edit, convert back.
And with HTML you'll still have to specify what subset you support, and many tools won't support that either. Markdown suffers from this too, by supporting embedded HTML, though at least commonmark is pretty baseline and well supported.
<message>
<body>This XEP supports many things:
* inline markup
* code blocks
* lists
* and possibly more!</body>
<markup xmlns="urn:xmpp:markup:0">
<list start="31" end="89" ordered="false">
<li start="31"/>
<li start="47"/>
<li start="61"/>
<li start="69"/>
</list>
</markup>
</message>My own preference goes to NOSTR, just a set of public/private keys as identity and nothing else needed.
Thank you for the reference to that project called anproto, never had heard of it and I'm still without understanding what problem it really solves. Seems to encrypt texts but then contains zero outside metadata to route it somewhere. The website is very scarce on details for someone unfamiliar the scuttle-something they mention.
https://news.ycombinator.com/item?id=9772968
https://news.ycombinator.com/item?id=31133082 (article and discussion)
But TL;DR:
* It's hard to even parse, XMPP uses an uninterrupted XML stream. * The contents are often baroque and complex * Standards are a mess, and stuff that should be in core isn't * Data loss is possible * Protocol wasn't made for mobile devices * Multiple devices are terribly supported * Data loss is possible
From my attempts long ago, and other testimonials, writing an XMPP client is a full time job of solving weird problems that shouldn't exist in something better designed.
I can't take this write-up seriously if it starts like that. I still read the whole thing though and I couldn't find any solid argument as to why someone would prefer XML to JSON for XMPP.
> This is especially true in browser environments, where XMPP streams run over WebSockets, which naturally frames the XMPP protocol. That’s why you are never actually working with XML trees consuming large chunks of memory. Modern implementations like XMPP.js go further and use LTX—a lightweight parser built specifically for XMPP’s streaming model—rather than the browser’s DOM parser. The result: developers work with JSON-like objects anyway. The wire format becomes invisible to your application code.
That to me, is an argument for using JSON, not XML. XML is strong when you have elements referencing other elements in your document structure or DOCTYPE for grammar defs. I might be missing something but I don't get how streaming XML is to be preferred over JSON for XMPP.
>> XML remains the best format for representing trees—deep hierarchies of nested data. JSON handles flatter structures well, but good messaging protocols are extensible: extensions can be embedded at different levels and composed together, like Lego bricks. That’s where XML shines.
Anything reasonable you'd be doing with messaging protocol is pretty flat.
Good protocols are opinionated and make concrete choices.
Extensibility typically leads to compatibility issues like the ones you are describing.