Why Matrix won

Some time ago I have been going full-in into my Prosody server and have finally reached a point where the server passes almost all of the tests on Conversation's XMPP compliance website (you can run the caas program locally).

All it is missing are the following tests:

XEP-0368: SRV records for XMPP over TLS                          FAILED
XEP-0411: Bookmarks Conversion                                   FAILED

Informational tests:
XEP-0077: In-Band Registration                                   FAILED
XEP-0157: Contact Addresses for XMPP Services (Abuse)            FAILED

As for the Informational tests, I know they will not pass because this is not a public server.

But why did the two above fail then?

The decentralization dilemma

I have been an XMPP user since I dipped my feet into the world of federated/decentralized messengers and so far, it has been great.

I started out with Matrix though and eventually moved to XMPP, then went back to Matrix for various reasons (mostly because I deployed then totally alpha-quality Dendrite instead of Synapse for quite a while).

Most importantly, the reason I switched to XMPP was because of its totally decentralized nature: XMPP is somewhat like e-mail, where everyone hosts their own server “independently” from other servers and carry their own share of issues or fixes.

We all know that matrix.org is the biggest Matrix homeserver, with the most amount of users and rooms, disproportionately bigger than any other homeserver (because it is run directly by the peeps over at the Matrix Project).

Believe it or not, this is sort of a good thing: what this allows the Matrix people to do is to update frequently and “force” other homeservers to update relatively quickly as to not break federation or features with matrix.org.

This is actually great for an ecosystem like the open source one, where things move fast and matrix.org allows everyone to be on their same level, maintaining a high standard of quality.

You probably see where this is going...

“The ecosystem is moving”

You probably have already read Moxie's opinion on why they chose a non-federated service for Signal; here are some snippets from the article that explains my frustrations with XMPP:

We got to HTTP version 1.1 in 1997, and have been stuck there until now. Likewise, SMTP, IRC, DNS, XMPP, are all similarly frozen in time circa the late 1990s.

What we have instead is a complicated morass of XEPs that aren’t consistently applied anywhere. The implications of that are severe, because someone’s choice to use an XMPP client or server that doesn’t support video or some other arbitrary feature doesn’t only affect them, it affects everyone who tries to communicate with them. It creates a climate of uncertainty, never knowing whether things will work or not. In the consumer space, fractured client support is often worse than no client support at all, because consistency is incredibly important for creating a compelling user experience.

The above could not be more true.

XMPP is fairly stagnant and my favorite example for this is OMEMO, the E2E encryption that is commonly used for chats: the XEP is at version 0.8.3 as of mid-2022 but none of the clients implement that version because “it breaks compatibility with the older OMEMO 0.3.0” (used by every XMPP client except UWPX that today sports 0.8.1 and is a Windows-only client).

The mentality behind this is essentially “if nobody uses it, don't implement it”, dragging the whole ecosystem into stagnation even though both 0.3.0 and today's 0.8.3 could co-operate on the same client at the cost of added client complexity.

This gives the impression that OMEMO is not actually complete as 0.3.0 does not contain any mention of the double-ratchet algorithm, threat models or usage in MUC rooms.

As an added bonus, the C Signal library implementing OMEMO is being forked over and over as upstream is dead in favor of a new Rust library, leading to projects reinventing the wheel and having different featuresets for OMEMO.

Other honorable mentions for the failing tests at the beginning are XEP-0368 and XEP-0411: passing the test for the first XEP requires you to specify in Prosody legacy_ssl_ports = { 5223 } so that clients could connect to that port via direct TLS, but the only mention of 5223 that I was able to find is in XEP-0035, which was last updated in 2003 (19 years ago...) and explicitly mentions:

Accordingly, the use of port 5223 and port 5270 for secure sessions is deprecated.

Direct TLS was also not implemented at all in Prosody 0.11 and earlier, so when version 0.12 started hitting other servers it left me unable to communicate with them with a generic “Delivery failed”, and clients like Gajim would not let you log in, marking XML streams as ill-formed.

Meanwhile, the latter test requires you to enable the mod_bookmarks module, which was deprecated years ago and was for clients that utilized XEP-0048 when nowadays we have XEP-0402.

Thankfully, XEP-0411 was removed from the caas test suite earlier this year as it was deprecated in 2021, but was kept around for a painfully long while.

The initial bringup

Setting up an XMPP is (IMHO) an absolute nightmare between configuring DNS records correctly, reading whole XEPs as other online documentations are outdated, choosing the correct modules (at least in Prosody's case) and so forth.

Then come the tests which verify outdated settings and make you look and feel bad in case you do not pass them, which is especially true for public servers.

Matrix, meanwhile, has the advantage of being very simple to deploy, almost all of the clients support the necessary MSCs and the documentation for server admins is “OK”.

While there are rumors stating that the actual Matrix spec is painful to read, being able to deploy a homeserver without reading it is a very welcome addition.

Conclusions

So far, Matrix is a good “replacement” for XMPP, even though I would love for both of them to co-exist, although XMPP in its current state and current (now becoming niche) community does not give any high hopes for a bright future.

My personal worry with Matrix is that the spec might become excessively big and writing clients will become a very hard task to include all its features.

So far, writing new Matrix servers is already a humongous task and demonstrates why everyone is leeching onto Synapse and not testing/contributing to alternative ones like Dendrite, Conduit or Construct.

On the metadata side of things, it seems that P2P Matrix will eventually become the “standard” version of Matrix and that will greatly reduce the amount of metadata that is shared over homeservers unencrypted.

I hope for the best for both projects and thanks for reading!