Surprisingly short text for how long it sets up an analogy with little value.
The problem with XMPP has always been that it is too extensible with too few guarantees in interoperability. You'll know what this means if you ever set up OMEMO over 3 different client implementations. It also does too much, anything from Kafkaesque (pun intended) persistent pubsub to content labels. The quality of clients is simply not good enough, so most XEPs end up in specialized variants of clients or proprietary implementations (Facebook, GTalk, EA Origin) that lean more on ejabberd's scalability than other XMPP features like federation.
Also, XML is not a good serialization format, and some of the requirements in the protocol are pretty exotic and not trivial to implement in a lot of languages. Like setting up TLS on an existing connection (plus the absolute refusal of the XMPP WG to allow on-connect TLS). JSON over websocket or HTTP are just better at reaching a wide audience of developers.
If XMPP and Matrix were based on the same protocol stack arguments to keeping XMPP this whole time would have made sense.
But they aren't. Matrix is http and json while XMPP is tcp and xml. Protocol extensions to xmpp have added http transports - but thats just wrapping non-http requests in http and making processing harder.
I think a good comparison is X11 vs Wayland. X11 was retrofitted with all the functionality Wayland has natively - "why switch" is a legitimate question. But we will see in the next 20-30 years how the maintenance burden of X protocol legacy means we will see any new development using Wayland because its so much easier to do. In the same sense, chat apps will probably favor Matrix over XMPP because of the protocol maintenance burden - even when drop in libraries exist that implement XMPP, the inherent complexity makes them buggier, slower, and requires a lot of developer nuance to get right and its all due to legacy cruft you have to accommodate on an old standard.
Its also like how more modern kernels stopped trying to be Unix compatible. Trying to meet the POSIX standard in the 21st century is kinda a waste of effort when a lot of it is unnecessary. The model is sound, its just adhering strictly to the eccentricities of it is just unnecessary headache.
I was impressed at how easy it is to work with the matrix protocol. While playing around I was doing it all interactively in bash using curl. Want to read the latest messages? Curl the sync url. Want to send a new message? Post a small json object.
It’s actually easier to use by hand than IRC which requires holding an open connection and quickly responding to pings.
It becomes a little harder when end to end encryption is on but you just import the library they supply for almost every language and then e2e becomes transparent.
I tried to hack E2EE in by using Pantalaimon [0] but running that on a server with the necessary management capabilities is very tricky and doesn't do cross signing, so I've come to the conclusion that it's effectively useless for my use cases.
Every now and then I check back on the current state of E2EE in libraries and it does seem to be improving. Hopefully the entire process becomes easier next time I get the time to work on my proof of concept code.