Matrix - Documentation

What it is¶

Matrix is an open standard for decentralized, real-time communication, stewarded by the nonprofit Matrix.org Foundation. It's the architectural odd one out among the protocols in this series: it isn't built around a public feed at all. Matrix is closer to a decentralized, end-to-end-encrypted replacement for Slack, WhatsApp, or IRC than to Twitter — it's solving group/private messaging, not public broadcast, and that difference in goal explains almost every other architectural choice Matrix makes differently from [[activitypub|ActivityPub]] or the [[at-protocol|AT Protocol]].

Architecture: rooms with no owner¶

Communication happens inside rooms. Unlike an ActivityPub post (which lives on its author's instance) or an atproto record (which lives in its author's PDS), a Matrix room's full state is replicated across every homeserver that has a user participating in it — no single homeserver owns or controls a room. Users register on independent homeservers (@you:homeserver.example), which act as their agent: storing their account, executing actions on their behalf, and listening for events on their behalf.

Room history is modeled as an event graph — a directed acyclic graph (DAG) of signed events, each referencing its "parent" event(s). Events split into two kinds:

Message events — transient activity: instant messages, VoIP call setup, file transfers.
State events — persistent room metadata: name, topic, membership, power levels, join rules. State is a lookup table keyed by (event type, state_key); each new state event for a given key updates that key's value.

State resolution: the hard part¶

Because multiple homeservers can generate events concurrently, and messages can arrive at different servers in different orders, Matrix needs something neither ActivityPub nor atproto requires: a formal state resolution algorithm that guarantees every homeserver converges on the identical final room state, deterministically, regardless of delivery order or which server produced which event. This is a genuine distributed-systems consensus problem, not just best-effort push (ActivityPub) or a single ordered firehose (atproto).

State Resolution v2 — the current algorithm — works by reverse-topologically sorting conflicting state events and breaking ties deterministically using power levels, timestamps, and event IDs, so that every participating server, computing independently, arrives at the same answer. This is also Matrix's known scaling pain point: in rooms with large, heavily-branching event histories, state resolution becomes genuinely computationally expensive, and it's an active area of protocol and implementation optimization work.

Federation: the Server-Server API¶

Homeservers exchange events over the Server-Server (Federation) API — HTTPS requests authenticated both at the TLS layer and via public-key signatures in HTTP Authorization headers. Events are packaged as PDUs (Persistent Data Units) and, like email, it's the originating server's responsibility to deliver a PDU to every other server that needs it — pushed over what's currently a full-mesh topology per room (every participating server talks directly to every other one, rather than through relays or aggregators the way atproto uses relays).

Encryption: Olm and Megolm¶

This is Matrix's other defining architectural piece, and something neither ActivityPub nor atproto has as a native, default capability: end-to-end encryption, on by default for private rooms in mainstream clients.

Olm handles 1:1 device-to-device sessions. It's Matrix's implementation of the Double Ratchet algorithm (the same cryptographic family underlying Signal), giving forward secrecy for direct exchanges between two devices.
Megolm handles group encryption efficiently. Rather than every message being individually Olm-encrypted to every recipient device (which doesn't scale to large rooms), each sender maintains its own ratcheting "outbound session" and encrypts each message once; that session's key state is shared to other devices in the room via ordinary 1:1 Olm exchanges, and each recipient maintains a corresponding "inbound session" to decrypt.

Because message history sharing to a newly-joined device is a legitimate, common use case (unlike in a pure Signal-style 1:1 chat), Matrix's encryption design explicitly supports deciding how much history a new device gets access to — a deliberate, documented departure from "classic" Double Ratchet purism, where sharing history at all is normally treated as a privacy hole to avoid.

Spaces, and the wider feature set¶

Spaces — collections of rooms, essentially "a room whose members are other rooms" — are Matrix's mechanism for organizing related rooms into a navigable hierarchy (a community's general chat, off-topic, and announcements rooms grouped together, for example). Beyond messaging, Matrix also natively supports VoIP/video calls, typing indicators, read receipts, presence, and a large third-party bridging ecosystem connecting Matrix to other chat networks entirely — Discord, Slack, IRC, WhatsApp, Signal, and more — which is a different kind of bridging than Bridgy Fed's ActivityPub↔atproto translation, aimed at chat interop rather than public-feed interop.

Homeserver implementations¶

Matrix is "just a spec" — multiple independent homeserver implementations exist:

Synapse — the original, Python-based, by far the most widely deployed.
Dendrite — a second-generation Go implementation aiming for a more efficient, microservice architecture; reached full server-server API parity with Synapse but is still behind on some client-server features.
Conduit — a lighter-weight Rust implementation aimed at small/personal deployments.

Identity and moderation¶

Identity is @user:homeserver.example — tied to your homeserver, the same structural tradeoff ActivityPub makes (no DID-style portability the way atproto has). Moderation is layered: within a room, power levels (a numeric permission system) control who can kick, ban, redact messages, or change room settings; at the network level, homeserver admins can block other homeservers entirely, similar in spirit to ActivityPub's defederation. The Matrix.org Foundation has also been moving toward curated room directories — vetted, moderated public room listings — as a response to safety and discoverability problems with a fully open public room directory.

Strengths and weaknesses¶

Strengths: real end-to-end encryption by default, a genuine distributed-consensus model rather than best-effort push, mature and widely deployed, solves a different (arguably harder) problem than public-feed social media, extensive bridging into non-Matrix chat platforms, nonprofit governance.

Weaknesses: large rooms are a real, acknowledged performance bottleneck due to state-resolution cost; identity isn't portable across homeservers the way atproto's DIDs are; it's not really competing in the same space as Mastodon or Bluesky, so comparing "which is better" across all three is often a category error rather than a genuine tradeoff.