Signal works well when everyone involved trusts the same company. Matrix is built for the case where they don't — where organizations want to run their own servers, where communities need to control their own infrastructure, and where interoperability across organizations matters more than simplicity.

Matrix is an open standard for real-time communication. Not an app, not a company's product — a protocol specification, maintained by the Matrix.org Foundation, that anyone can implement. The most prominent client is Element (formerly Riot), but the protocol supports a wide range of clients and server implementations. Understanding Matrix requires understanding why federation was the core design goal, and what that goal costs in complexity.

Federation: What It Means and Why It Matters

Federated protocols allow servers run by different organizations to communicate with each other. Email is federated: a Gmail account can exchange messages with a Fastmail account and a self-hosted Postfix server. No single company owns email. Matrix works the same way for instant messaging: a user on matrix.org can be in the same room as a user on a university's homeserver, a company's self-hosted Synapse instance, and a self-hosted instance run by an individual.

The alternative — what Signal, WhatsApp, iMessage, and Telegram use — is a centralized model: all users register with one company, all messages route through that company's servers. This is simpler to operate and easier to reason about cryptographically, but it creates a single point of control. The company can be compelled by courts, can unilaterally change terms of service, can go bankrupt or be acquired, or can simply decide to block users in certain jurisdictions.

Federation distributes that control. No single party can shut down the Matrix network any more than a single party can shut down email. An organization that wants guaranteed access to its own communications can run its own homeserver and not depend on any third party remaining operational or cooperative.

The Matrix Identity Model

Every Matrix user has a Matrix ID of the form @username:homeserver.tld — analogous to an email address. The homeserver portion identifies which server manages that account's identity and stores their messages. A user on matrix.org has IDs like @alice:matrix.org; a user on a self-hosted server at corp.example.com has IDs like @bob:corp.example.com.

Rooms in Matrix are identified by room IDs (internal) and room aliases (human-readable, like #general:example.com). When a room has participants from multiple homeservers, each homeserver stores a copy of the room's event history. This replication is what makes federation work without a single authoritative server — but it also means the room history is stored in multiple places, and deleting a message requires cooperation from all participating homeservers.

The Room State Graph

Matrix's data model is unusual: a room is represented as a Directed Acyclic Graph (DAG) of events. Each message, membership change, or state update is an event that cryptographically references the events that preceded it. This structure is what allows multiple homeservers to replicate and merge room state without a central sequencer — servers can receive events out of order, detect forks (when two servers each received different events claiming the same "previous event"), and resolve them deterministically.

The state resolution algorithm is one of the more complex parts of the Matrix specification. The current version (State Resolution v2) is designed to handle Byzantine conditions — scenarios where a homeserver is misbehaving or partition-healing after a network split — without allowing any single server to roll back the room's history or exclude valid events.

Encryption in Matrix: Olm and Megolm

Matrix's end-to-end encryption uses two related but distinct cryptographic ratchets, both implemented in the libolm library (and its newer Rust successor, vodozemac):

Olm is used for 1:1 encrypted sessions between devices. It implements a Double Ratchet construction (the same design underlying the Signal Protocol), providing forward secrecy and break-in recovery. Each device-to-device session has its own Olm session; if one session key is compromised, past messages in that session retain forward secrecy.

Megolm is used for group rooms. It uses a single ratchet per room per device rather than per-message device-to-device sessions. This is a deliberate performance trade-off: in a 200-person room, encrypting each message with 199 separate Olm sessions would be prohibitively expensive. Instead, a sender generates a Megolm outbound session, distributes the current ratchet state to all room members (via Olm-encrypted to-device messages), and then encrypts messages using the shared Megolm session.

Megolm vs. Per-Message Ratchet: The Forward Secrecy Trade-Off

Megolm's single ratchet per session provides forward secrecy within that session — messages encrypted at ratchet position N can't be decrypted using a key derived after position N. But since all room members received the same initial session key, a device that obtained the starting Megolm key can decrypt everything encrypted in that session. This is structurally different from Signal's per-message Double Ratchet, which provides stronger compromise recovery guarantees. It's a deliberate trade: group performance over maximal forward secrecy.

Key verification in Matrix works via cross-signing: each user has a master key, a user-signing key, and a self-signing key. Verifying another user means verifying their master key, typically via a QR code scan or emoji comparison during an interactive verification session. Once verified, that user's devices are trusted for encrypted communication without per-device verification.

Matrix vs. Signal: Different Problems, Different Solutions

Signal's centralized model allows it to make strong, consistent guarantees about protocol behavior — there's one reference implementation and one server, so the encryption invariants are easier to audit and enforce. Matrix's federated model is more complex: the security of a conversation depends on the behavior of all participating homeservers, and a compromised or malicious homeserver can observe unencrypted room events (in non-E2EE rooms) or metadata.

Bridges: Matrix as a Universal Messaging Hub

One of Matrix's most practically useful features is its bridge ecosystem. A bridge is a bot-like process that translates between Matrix's protocol and another messaging platform's API. Bridges exist for Telegram, WhatsApp, Discord, Slack, IRC, Signal, SMS, and many others. The result is that a Matrix homeserver can act as a hub: messages sent from Discord arrive in a Matrix room, replies from Matrix users are forwarded back to Discord.

The security implications of bridging are real and worth stating plainly: bridged messages are not end-to-end encrypted between the two platforms. A message from Matrix to a WhatsApp bridge decrypts on the bridge server before being transmitted to WhatsApp's infrastructure. Bridges are useful for consolidation and convenience; they don't preserve the encryption guarantees of either platform.

The Honest Trade-Offs

Matrix solves the federated, decentralized, self-hostable encrypted messaging problem better than any other protocol at production scale. It also carries costs that Signal doesn't:

• Operational complexity — running a Synapse homeserver requires maintenance, storage planning, and attention to upgrades
• Metadata exposure to homeservers — your homeserver admin can see who you talk to, when, and in which rooms (for non-E2EE rooms, the content too)
• Key management complexity — cross-signing verification, key backup configuration, and device trust management are non-trivial for non-technical users
• Federation amplifies bugs — a state resolution bug on one homeserver can affect all rooms that server participates in

Matrix is the right choice for organizations that need to own their infrastructure, for communities that need governance independent of any single company, and for technical users who want federation over simplicity. For individuals who want maximum encryption assurance with minimal configuration, Signal's simpler model is probably the better fit — as we discussed in our post on the trade-offs in Signal's design.

The two protocols aren't competing for the same use case. They're solving different versions of the secure messaging problem, and knowing which version you have determines which tool fits.

---

Originally published at havenmessenger.com