XMPP: The secure communication protocol that respects privacy

XMPP has had e2ee for years. What are your criterias for calling it not secure ?

XMPP leaves a lot of metadata and user information around, so it does have a privacy issue that's probably not solvable. Whether it's a security issue is a completely different discussion though.

That's got nothing to do with the security problems OP complained about though. Are there even working solutions to those metadata problems apart from sending dummy decoy messages and purposeful delays on the server side to make correlating message relaying hard?

The article describes XMPP as "secure" by highlighting TLS (protecting data in transit only) and experimental OMEMO (protecting a small part of an XMPP message only if enabled and working). What about other crucial security features, see https://www.eff.org/deeplinks/2018/03/building-secure-messen...?

Then, XMPP is described as "privacy respecting" mostly because you can use a nickname instead of a phone number for your account. What about all of the cleartext data and metadata that can be accessed by parties on the XMPP server, like the XMPP server admin, see https://infosec-handbook.eu/articles/xmpp-aitm/?

This logic implies that e-mail is also secure and privacy respecting.

> 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.