> How would it be even possible to build Matrix, as it is today, on XMPP? And, more importantly, why would you want to do that?
Glad you asked! There's two main components to Matrix: the client-to-server (c2s) and server-to-server (s2s) APIs.
The c2s API on matrix is of little to no value and could have been implemented as an HTTP API to XMPP servers: the way this is done in the XMPP ecosystem is with BOSH so we wrap the XMPP protocol inside an HTTP-based bidirectional stream, but there's no reason you can't make a "native" HTTP API for your XMPP server.
The s2s protocol is the interesting part of matrix because it has a genuinely-useful property of treating a room as a single state handled by a consensus of varied servers. The usual XMPP protocol MUC is ill-suited for that, but the "new" (~2015) MIX specification is based on a pubsub model very similar to Matrix and building a consensus algorithm on top of that would certainly not be harder than to develop an entirely new protocol from scratch.
Now as for why you would want to do that: to avoid fragmenting the ecosystem. XMPP was developed to address technical limitations of IRC, which is not an extensible protocol (does not use namespaced trees for messages) ; implementing a new feature in IRC is always at the risk of breaking clients and the IRCv3 working group spends a lot of time trying to work around that. XMPP was from the start conceived to be extensible and so there was little reason to reinvent a new protocol and software ecosystem just to add a single feature (decentralized rooms).
After all, matrix and XMPP have the exact same selling points (over a decade apart): federated and interoperable communications with bridges to 3rd party protocols. Now we have two protocols to address the same use-case, each with their up and downsides but certainly both further away from their goals than they would be if they mutualized efforts instead of reinventing the wheel. I have criticisms of XMPP just like i have criticisms of HTTP/HTML. But i personally do not understand the appeal to reinvent an entirely new markup language and browser/server ecosystem just because i'd like support for a new HTML element.
As someone who selfhosts Matrix and XMPP (thanks, Snikket!) I don't understand why Matrix is so terrifically burdensome to maintain if it is indeed competing. I've had three Matrix deployments all go wonky in various ways. I'm finally fed up with the Python implementation and hoping that the Rust implementation will solve all my woes.
XMPP clients running on a tiny VPS just feel very fast in comparison to Matrix clients running through a much larger VPS. Rooms still take ages to join whereas Snikket joins almost instantly. I've spent truly astounding amounts of time debugging Matrix's Postgres database, to video calls to Discord bridges. Snikket just keeps on ticking no matter what I throw at it.
It's starting to feel like the spec itself might be to blame but I welcome the input of experts, such as yourself.
The benefit would be that history would be kept and be viewable from different accounts. The problem would be that the history would have to be MITM'd on the matrix-xmpp-server-bridge because the encryption models aren't compatible. The server would need to manage omemo keys for the user and would thus need ultimate trust.
XMPP has pubsub nodes, which in practice can be used as a general key-value datastore with a push when a key is updated. So it can be done, but at this point it will only be the same functionality with a different API. It doesn't make a lot of sense.
And, more importantly, why would you want to do that? What would be the benefit if that was done?