End-to-end encryption is now table stakes. WhatsApp has it. iMessage has it. Even Facebook Messenger has it. The interesting question for anyone serious about communications security has shifted: not whether the message content is encrypted, but what the network sees about the act of sending it. Who is talking to whom, when, from where, on which device, and whether those facts can be reconstructed later by a server operator, a subpoena, or a passive observer.
That question separates Signal, Session, SimpleX, and Matrix into four genuinely different threat models. Each one defines “anonymity” against a different adversary, and each one makes a different bet about which surveillance vectors matter most. This piece walks through what each system actually protects, where it leaks, and how to choose between them when content encryption is a baseline rather than a feature.
What Each System Is Actually Protecting
Signal is a centralized service operated by the US-based Signal Foundation. It protects message content with the Signal Protocol — the double-ratchet design that WhatsApp, Google Messages, and Facebook Messenger licensed for their own E2EE implementations. Signal’s anonymity story rests on minimizing what its central servers retain: registration date, last connection time, and not much else. Sealed Sender hides the sender identifier from the server on a per-message basis, and private contact discovery uses Intel SGX enclaves and private set intersection so the server can match contacts without learning the social graph in plaintext.
The unavoidable identifier on Signal is the phone number used at registration. Since February 2024, usernames and phone-number privacy settings let users hide that number from people they chat with, but registration still requires one. Signal can’t easily produce an associated username given a phone number, but the reverse mapping — phone number to account existence — is part of how the service works.
Session is a Signal fork that removed phone-number registration entirely and routes messages through a decentralized onion network. Identifiers are 66-character public keys called Session IDs. Messages travel through three-hop onion routes via the Oxen Service Node Network, where independent operators stake cryptocurrency to run nodes. No single node sees both origin and destination. Offline messages buffer in a small group of nodes called a Swarm until the recipient fetches them, also via onion routing.
In October 2024, stewardship of Session moved from Australia’s Oxen Privacy Tech Foundation to the Switzerland-based Session Technology Foundation. In May 2025, the project completed a migration off the Oxen blockchain onto a dedicated Session Network with an Ethereum-compatible Layer 2 token. The legacy oxen-io GitHub repositories were archived in late 2025. Session removed perfect forward secrecy from its protocol when it diverged from Signal’s design — a tradeoff that drew sharp criticism from cryptographers, including Soatok’s January 2025 posts. In December 2025, Session announced Protocol V2, which restores forward secrecy through rotating per-device keys and adds post-quantum key exchange based on lattice cryptography.
SimpleX takes the most aggressive position on metadata: there are no user identifiers at all. Not phone numbers, not usernames, not public keys, not even random account numbers. To deliver a message, SimpleX uses pairwise anonymous addresses of unidirectional message queues, with separate addresses for sending and receiving, typically via different servers. Each contact gets its own queue pair. Trail of Bits completed a security review of the protocol design in October 2024 (released alongside v6.1). Since v6.0, private message routing is on by default, using a two-hop forwarding scheme that prevents the destination server from linking messages to a single user. v6.2 in December 2024 added Flux-operated preset servers to broaden the relay infrastructure beyond servers run by SimpleX Chat Ltd.
Matrix is a federated protocol — closer to email or XMPP than to Signal in its threat model. Users register on a homeserver (the default matrix.org is operated by Element in the UK), and rooms replicate across all participating homeservers. Content encryption uses the Olm and Megolm protocols, which provide guarantees comparable to Signal Protocol and its Sender Keys variant respectively. The federation layer, however, is where Matrix’s anonymity story gets complicated: room membership, message timing, device IDs, and server addresses pass between federating homeservers in plaintext. Every homeserver participating in a room receives a full copy of the event graph, including history.
Where Each One Leaks
Every system in this comparison has metadata exposure. The interesting question is to whom, and what they can do with it.
Signal’s central server learns the registration phone number, knows when an account was created, and sees the IP address each time a client connects. It does not see who you message (Sealed Sender), what you say, your contact list (private contact discovery), or your group membership. Signal’s published transparency reports show its responses to legal demands — typically just registration date and last connection timestamp. The exposure that matters most is structural: a phone number is a strong real-world identifier in jurisdictions that require KYC for SIM cards. If your number ties to your real identity, your Signal account does too.
Session removes the phone number entirely, which closes Signal’s biggest identity exposure. Onion routing through the Service Node Network prevents any single node from seeing both ends of a conversation. Service Nodes only see encrypted payloads and partial routing information. The remaining exposures are well-documented by the project: onion routing adds latency, push notifications still rely on Apple and Google infrastructure, and the network is not designed to defeat a global passive adversary capable of traffic correlation across large portions of the internet. Session also has a real-world reliability problem — community reports of message delivery failures in groups and sync glitches across devices have pushed some users toward SimpleX.
SimpleX has the strongest metadata story by design. No user identifiers means no social graph for any single server to reconstruct. Each conversation uses different sending and receiving servers, so even a server operating both queues for a contact only sees opaque queue IDs, not user accounts. Private message routing wraps each packet in an additional layer that hides the destination queue from a forwarding server. Trail of Bits validated the protocol design in their 2024 review. The leakage that remains: SimpleX clients on iOS still depend on Apple’s push notification infrastructure (notifications carry encrypted metadata only, not content); message timing correlation by a powerful network observer is still theoretically possible; and the protocol is younger and less battle-tested than Signal’s.
Matrix is the outlier. Content encryption via Olm/Megolm is solid — the cryptographic suite has been formally analyzed in academic work — but the federation model leaks structural metadata as a feature, not a bug. Sender, recipient, device ID, room membership, and timestamps cross homeserver boundaries in plaintext. Every homeserver participating in a room receives the full event graph. The default matrix.org homeserver is in the UK, which carries its own legal-jurisdiction implications. Self-hosting eliminates the matrix.org exposure but doesn’t fix the federation leak as long as the people you’re talking to are on other servers.
| Exposure vector | Signal | Session | SimpleX | Matrix |
|---|---|---|---|---|
| Account tied to real-world identifier | X | A | A | P |
| Server can build social graph | A | A | A | X |
| IP address visible to relay/server | X | A | A | X |
| Room/group membership exposed | A | A | A | X |
| Vulnerable to global passive adversary | X | P | P | X |
| Push notifications use platform infra | X | X | P | X |
How Onion Routing and Pairwise Queues Actually Work
The two designs that go furthest on metadata — Session’s onion routing and SimpleX’s pairwise queues — solve the same problem in opposite ways. Worth understanding the difference because it affects what each can and can’t protect against.
Session’s approach is borrowed from Tor. When a client sends a message, it picks three Service Nodes from the Oxen network and wraps the message in three layers of encryption, one per hop. Each node decrypts only its layer, learns only the next hop, and forwards. The first node sees the sender’s IP but not the destination; the third node sees the destination but not the sender; the middle node sees neither endpoint. Recipients fetch from their Swarm — typically seven Service Nodes assigned by the network — also via onion routes. The protection holds as long as no single adversary controls enough nodes to deanonymize a route by chance, and as long as the adversary can’t observe traffic at both ends simultaneously.
SimpleX doesn’t route through onions. Instead, every contact pair gets a dedicated queue with a unique address that no other contact knows about. The relay server passing messages for that queue has anonymous credentials per queue and no knowledge that the queue belongs to a specific user — there is no user concept at the server. Sending and receiving typically use different servers, so no single relay sees both directions of a conversation. The queue identifiers themselves are pairwise: visible only to the two participants. Where Session hides identity by mixing routes, SimpleX hides identity by never establishing one. Per-message private routing (since v6.0) adds an onion-style hop on top to prevent the destination relay from correlating multiple messages to the same client IP.
Both designs sacrifice something Signal preserves: unified accounts. On Signal, your phone number is your account, your messages sync across devices, and recovery is straightforward. On Session and SimpleX, recovery hinges on a key or seed phrase, which is unforgiving — losing it means losing the account permanently, with no recourse.
Where Matrix Fits
Matrix isn’t trying to win the metadata-minimization fight. Its design priorities are open federation, interoperability, and rich collaboration features — voting, threads, spaces, bridges to Slack and Discord and WhatsApp. The federation model that leaks metadata is the same model that lets organizations self-host, choose jurisdictions, and bridge to legacy systems.
For community coordination — open-source projects, technical groups, organizations that need rooms, threads, and integrations — Matrix is genuinely useful. For high-stakes anonymity, where the question “did Alice talk to Bob, and when” must remain unanswerable, it’s the wrong tool. Critics including Wire have published detailed arguments that Matrix’s metadata exposure is incompatible with strict EU privacy requirements. The Matrix project has acknowledged the limitation and points to in-progress work on P2P Matrix as an eventual mitigation, but that work is not yet production-ready.
Some practical implications worth flagging: a Matrix user’s IP address can be leaked through certain link-sharing flows; user IDs in the form @user:server reveal the homeserver they belong to; and the default Element client routes through Cloudflare for the matrix.org homeserver, adding another infrastructure operator to the trust chain.
Choosing Between Them
A few practical notes that don’t fit a comparison table:
If you’re using Signal and the phone-number link is your concern, an anonymously-acquired number from services like Silent.link or a cash-bought prepaid SIM separates the registration identifier from your real identity. Set “Who can find me by my number” to “Nobody” and share usernames instead. This isn’t perfect — Signal still stores the number — but it eliminates the most common deanonymization path.
If you’re using SimpleX, route through Tor when threat models call for it. The app supports SOCKS proxy configuration. Even with private message routing on, the IP address visible to your relay is your real one unless you tunnel.
If you’re using Matrix, self-host the homeserver and accept that anyone you message on a different homeserver still leaks the conversation’s existence to that homeserver’s operator. For organizational use this is usually acceptable; for source-journalist work it usually isn’t.
Common Questions
Is Signal still the safest choice for most people? Yes, with the caveat that “safest” depends on what you’re defending against. For protecting message content from interception, Signal remains the gold standard. For protecting the fact that two specific people are communicating, SimpleX has a stronger architectural story.
Why did Session lose perfect forward secrecy, and is that fixed? When Session forked from Signal, it adopted a simpler protocol that didn’t include the double-ratchet’s forward secrecy properties. The December 2025 announcement of Protocol V2 commits to restoring forward secrecy through rotating keys and adding post-quantum key exchange. Until V2 is broadly deployed, current Session conversations don’t have the same forward-secrecy guarantee Signal does.
Can law enforcement get my messages from any of these? Content, no — all four use end-to-end encryption. Account metadata varies. Signal has responded to subpoenas and published the responses, which typically contain only registration date and last connection time. Session and SimpleX servers retain almost nothing about users to compel. Matrix homeservers retain substantial metadata, and the legal jurisdiction of the homeserver operator matters.
What about endpoint compromise? None of these systems protect against malware on your phone or computer. If your endpoint is compromised — Pegasus, Paragon, similar — the attacker reads messages before encryption regardless of which app you use. GrapheneOS reduces this risk on Android. Endpoint security is a separate problem from messenger choice.
What This Comparison Doesn’t Resolve
The four systems aren’t ranked because they’re optimizing for different things. Signal optimizes for usability with strong content security. SimpleX optimizes for metadata invisibility. Session optimizes for anonymous registration with onion-network routing. Matrix optimizes for federation and feature richness.
The one tool nobody serious should use as a default is the one that hasn’t been mentioned: any messenger without genuine end-to-end encryption, or with E2EE that’s opt-in rather than always-on. That’s the bar these four all clear. The interesting choice happens above it.
Pick based on what you’re actually defending against, not the marketing. Run more than one if your threat model is layered — a SimpleX channel for sensitive contacts, Signal for daily messaging, Matrix for community work, with the understanding that running multiple messengers expands the attack surface across more push channels, more logs, and more ways for behavioral patterns to correlate.
