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've tried to set up some Matrix projects. The Client-Server API is easy to work with, but as soon as encryption is involved, things start getting messy. Many libraries have a hard time working right with E2EE enabled, because suddenly you need to keep track of all manner of things that aren't always documented well.
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.
> I was impressed at how easy it is to work with the matrix protocol
I think you were interacting with Synapse, the Matrix homeserver implementation, which is why you had an easy time. But I can't imagine the work done by Synapse to sync up with other servers is easy - and that's what I would consider the real protocol.
There are two protocols. The Server-Server protocol, and the Client-Server protocol. Both are "real". I was using the Client-Server protocol which synapse implements but other servers would implement exactly the same HTTP protocol.
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.