XMPP at 25: The Case for Treating Messaging as Infrastructure
A look at why XMPP's open standards approach matters for digital sovereignty, and why open-source walled gardens like Signal and Matrix fall short.
Twenty-five years in, Jabber—now XMPP—remains the only messaging protocol designed as true infrastructure. The argument from the XMPP community is simple: communication tools are infrastructure, and infrastructure must be built on open standards, not corporate-controlled platforms.
The piece draws a sharp line between open-source and open standards. Signal, Wire, and Threema are often praised for ethical practices, but they are still walled gardens. Open-source code doesn't protect users if the company shuts down servers or changes policies. Standards, on the other hand, ensure that any provider can be replaced, and that self-hosting remains possible.
The critique extends to Matrix, which is often seen as the modern alternative. Despite its federation, Matrix is controlled by Element, with a single dominant implementation and a resource-intensive server that makes self-hosting difficult. The author contrasts this with JMAP, which went through the IETF process and now has multiple independent implementations.
XMPP's strength is its extensibility. The XEP process allows the protocol to evolve, but it's been slow. Mobile support took years to mature, and E2EE only became widespread after Snowden. The community is now working on modern features like message replies, multi-image sharing, and OAuth, with an eye toward an XMPP 2.0 at the IETF.
The piece is a reminder that digital sovereignty isn't about swapping American corporations for European ones—it's about collective ownership and open standards that keep any single vendor replaceable.
Open-source software is orthogonal to this problem. It helps to ensure that the software isn't spyware, but it does not protect us if Signal shuts down its servers tomorrow.
| Protocol/Platform | Governance | Self-hosting | Interoperability |
|---|---|---|---|
| XMPP | XSF (open SDO) | Yes (multiple implementations) | Full federation |
| Matrix | Element-controlled foundation | Possible but resource-intensive | Federation, but single dominant implementation |
| Signal | Signal Foundation | No (centralized servers) | None |
| JMAP | IETF (open SDO) | Yes (multiple servers) | Standard email protocol |
Source: Daniel Gultsch
Discussion
0 Comments
Be the first to start the discussion.