Signal, SimpleX, Session, and Matrix: Choosing a Private Channel by Threat Model

“Just use Signal” is good advice, and for most people it’s the end of the conversation. But “is the message encrypted?” is the easy question. The hard question — and the one that actually determines whether a channel keeps you anonymous — is what does it leak about the fact that you’re communicating at all, and what identifier does it tie to you.

Content encryption is now table stakes; all four tools here have it. They diverge on metadata (who talked to whom, when, how often) and on identity (what you have to hand over to register). Those two axes, not the encryption itself, are what you should match against your threat model. This guide compares Signal, SimpleX, Session, and Matrix/Element on exactly those terms — and is honest about where each falls short. (For Briar, the peer-to-peer, server-less option, see our Signal vs Session vs Briar comparison.)

Signal: The Baseline, With a Phone Number Attached

Signal is end-to-end encrypted by default for messages and calls, using the audited Signal Protocol. It’s fast, well-maintained, and the safe default for almost everyone.

Identity: Signal requires a phone number to register. You can now set a username and hide your number from contacts, but the account itself is bound to a phone number Signal knows.

Metadata: This is where Signal is genuinely strong. Its architecture is designed to retain almost nothing — when served legal demands, Signal has been able to produce essentially only the account’s creation date and last connection time. Features like sealed sender further reduce what the server can see about who is messaging whom. The unavoidable residual metadata is the phone number itself, which is a link to your real identity.

The honest limit: the phone number. If your threat model requires that no identifier connect a conversation to your real self, Signal’s registration is a problem unless you can obtain a SIM truly anonymously — which in many jurisdictions you can’t.

Best for: the overwhelming majority of people who want strong encryption and minimal metadata, where being tied to a phone number isn’t itself the threat.

SimpleX: No User Identifier At All

SimpleX Chat takes the most radical position on identity: it has no user identifiers of any kind — not a phone number, not an email, not a username, not even a random user ID. This is its central, genuinely unusual design claim.

How it works: instead of identifying users, SimpleX delivers messages through the addresses of unidirectional message queues. Each connection uses separate queues for sending and receiving, routed through relay servers that hold messages only briefly and don’t talk to each other. No server has the full picture of your contacts, and there’s no central directory of users to compromise or subpoena. Encryption uses a double-ratchet implementation providing forward secrecy, with optional post-quantum extensions in newer versions.

Metadata posture: because there’s no account and no global identifier, there’s nothing to correlate you across conversations by default — the property most messengers can’t offer. You can run your own servers, and you can route connections over Tor for IP protection.

The honest limits: SimpleX is younger and less battle-tested than Signal, with a smaller (though growing) base of independent scrutiny. The no-identifier model has real usability costs — connecting requires exchanging an invitation link or QR code rather than looking someone up, and multi-device use is more involved. Relay operators can still observe traffic patterns at their own node even if they can’t link the whole conversation.

Best for: situations where the existence of an account tied to anything is unacceptable, and you’re willing to trade some convenience and maturity for that.

Session: No Phone Number, Onion-Routed — With a Forward-Secrecy Caveat

Session is a decentralized messenger that registers you with a long alphanumeric Session ID derived from a key pair — no phone number or email required. It routes messages with onion routing over a network of service nodes, so the node receiving a message doesn’t learn the sender’s IP. Stewardship of the project moved to the Session Technology Foundation (based in Switzerland) in late 2024.

The forward-secrecy nuance — read this carefully. Session removed classic perfect forward secrecy in 2021 for the sake of its decentralized, store-and-forward design. Its FAQ states that Session “currently mitigates some of the same risks that PFS does, albeit in other ways,” but the practical implication has been real: without per-message key rotation, an adversary who obtains your long-term key (via device seizure or malware) and has captured your past traffic could decrypt those older messages — a weaker position than Signal’s. Session has announced a Session Protocol V2 that re-introduces perfect forward secrecy and adds post-quantum encryption, but as of early 2026 V2 is not yet finalized or rolled out — Privacy Guides reported the plans in December 2025 with more details promised through 2026. Don’t assume the PFS upgrade is live until it actually ships.

Best for: communicating without a phone number when you accept the current forward-secrecy tradeoff, and value onion-routed IP protection. Verify the protocol version’s current state before relying on it for high-stakes work.

Matrix / Element: Federated and Flexible — But Metadata-Leaky

Matrix is an open, federated protocol; Element is its best-known client. Federation is its appeal: anyone can run a homeserver, you’re not locked to one company, and it’s strong for communities, bridging, and self-hosting.

The metadata problem you must understand. Matrix encrypts message content end-to-end, but a great deal of room metadata is stored on the homeserver in plaintext as “state events.” Element’s own engineering blog is candid about this: a room’s name, topic, and other metadata sit unencrypted on the server, and room membership is visible to it. There’s also a structural concern that, because room-management events aren’t fully authenticated, a malicious homeserver could in principle add a server-controlled member to an encrypted room. Work to encrypt state events (MSC3414) is in progress and explicitly incomplete — it’s not something to count on today.

The honest limit: Matrix protects what you say far better than the social graph and structure of where you say it. For an adversary who can see or compel your homeserver, that exposed metadata can be exactly what matters.

Best for: communities, federated/self-hosted setups, and cases where rich features and openness matter more than minimizing metadata. It is not the tool to pick when hiding the existence and shape of your conversations is the priority.

The Comparison

	Signal	SimpleX	Session	Matrix / Element
Identifier required	Phone number	None at all	Session ID (no phone/email)	Account on a homeserver
Content encryption	Signal Protocol	Double ratchet (+ PQ option)	E2EE, onion-routed	E2EE (Olm/Megolm)
Forward secrecy	Yes	Yes	Not currently (V2 planned)	Yes (content)
IP protection built in	No (use Tor/VPN)	Optional via Tor	Yes (onion routing)	No
Metadata posture	Very little retained	No user identifier; minimal	Decentralized; no phone	Room metadata visible to server
Maturity / scrutiny	Highest	Newer	Moderate	Mature protocol, leaky model

Choosing

• “I want strong encryption with minimal metadata, and a phone number is fine.” → Signal. Right for most people.
• “No identifier can exist that ties a conversation to me.” → SimpleX, accepting its relative youth and the usability cost of the no-account model.
• “I need to register without a phone number and want IP protection.” → Session, if you accept the current forward-secrecy tradeoff. Check whether Protocol V2 has shipped before trusting it for high stakes.
• “I want federation, self-hosting, or community features.” → Matrix/Element, with eyes open about server-visible metadata. Don’t use it where hiding conversation structure is the goal.

The thread tying all four together is the same one that runs through every tool we cover: encryption protects the channel, not your discipline. The most metadata-resistant messenger is undone the moment you log in with a recognizable handle, link it to an account tied to your real name, or run it on a compromised device. Pick the channel that matches your threat model — then back it with consistent operational habits, because that’s what actually keeps a conversation private.