# Your messenger keeps more than your messages — Signal vs SimpleX vs Matrix > Every serious messenger encrypts content now, so encryption is no longer the thing that separates them. What separates them is what each one is forced to keep about you anyway: whether it demands a phone number, what routing its servers log, and whether the design leaks your contact graph even when the ciphertext is flawless. Last week showed the envelope betrays you; this week is about which envelope is smallest. Markdown twin of https://xmr.club/opsec/15-secure-messengers. CC-BY-4.0. Attribute "xmr.club". ## At a glance - Canonical: https://xmr.club/opsec/15-secure-messengers - Series: #OPSEC52 — weekly threat-model-first OPSEC cards - Week: 15 - Pillar: Comms discipline - Difficulty: beginner - Cost: $0 - Published: 2026-08-31 ## Body # OPSEC52 / Week 15 — Secure messenger choice: Signal vs SimpleX vs Matrix > Every serious messenger encrypts content now, so encryption is no longer the thing that separates them. What separates them is what each one is forced to keep about you anyway: whether it demands a phone number, what routing its servers log, and whether the design leaks your contact graph even when the ciphertext is flawless. Last week showed the envelope betrays you; this week is about which envelope is smallest. **Threat model:** the messenger operator, whoever hosts its servers, and anyone who subpoenas, coerces, or breaches them. All the apps here are end-to-end encrypted, so the real question is not "can they read my messages" — it's "what identifiers and routing metadata does this tool structurally retain, and how much of my social graph can be rebuilt from it." A phone-number requirement or a chatty federation protocol gives up that graph no matter how strong the content crypto is. ## Judge a messenger on three axes, not on the encryption badge Almost everyone with a modern messenger uses the same crypto lineage (the Signal/Double-Ratchet protocol or something close). So "it's end-to-end encrypted" tells you almost nothing about your metadata exposure. Judge on these instead: 1. **Identifier required.** Does it force a phone number (a KYC-anchored, carrier-logged, cash-or-crypto-purchase-traceable identity) or does it let you exist as a random key? 2. **Server model and retention.** Centralized, federated, or peer/onion-routed — and what does the routing layer *have* to store to deliver a message? 3. **Graph resistance by design.** Even under perfect content encryption, can the operator see who talks to whom? That's the crown jewel and the whole point. ## Signal — best-in-class content, phone-number anchor Signal is the honest default. Its cryptography is the reference standard, and **sealed sender** hides the *sender* field from Signal's own servers for established contacts. Retention is genuinely minimal — repeated subpoenas have returned little more than account-creation and last-connection dates. The weakness is structural: **Signal requires a phone number.** That number welds every "private" chat to a SIM, a carrier record, and whatever KYC bought the SIM. Sealed sender protects the envelope's *from* line but the registration identifier still exists. Signal is an excellent choice for content secrecy and for most people's threat models — but if your adversary can subpoena a carrier, the phone number is the thread they pull. If you use it for anything sensitive, register with a **non-KYC number bought with cash or crypto**, never your real SIM. ## SimpleX — no identifiers at all **SimpleX** is the strongest metadata posture of the mainstream options because it has **no user identifiers whatsoever** — no phone number, no username, not even an account ID. Instead of "users who have addresses," it uses per-contact, one-time message queues; there is no central directory of who you are, so there is no global graph for a server to hand over. Even if you run a relay, it sees unlinkable queues, not "Alice talks to Bob." Trade-offs: a smaller network (you have to bring your contacts), a slightly rougher UX, and you must actually route it over Tor to hide your IP from the relays. But for the "who talks to whom" problem — the one that gets people killed — SimpleX is the closest to structurally solving it. ## Matrix — federated and powerful, but metadata-heavy **Matrix** (Element) is genuinely useful: federated, self-hostable, great for communities. But be clear-eyed — its content is E2E encrypted while its **metadata is not, and there's a lot of it.** Room membership, timestamps, reactions, and profile data are visible to your homeserver, and **federation spreads that metadata across every server a room touches.** A room with participants on ten homeservers means ten operators can see the membership and timing. Matrix is the *worst* graph-resistance of the three by default. If Matrix fits your use case, **self-host your homeserver** so at least your own account's metadata isn't sitting on someone else's box, and understand that anyone you talk to on a public homeserver is still a leak. Great for open community ops; poor for hiding a sensitive contact graph. ## The honorable mentions - **Session** — no phone number, onion-routed over its own network so servers never see your IP. Good identifier and network posture; smaller ecosystem, and it made cryptographic trade-offs (historically dropping forward secrecy) worth reading up on. - **Cwtch** — Tor-native, metadata-resistant, peer-to-peer. Excellent posture, most technical to run. ## The discipline: match the messenger to the threat model - **Sensitive contact graph → no phone anchor.** SimpleX, Session, or Cwtch. Not Signal-with-your-real-number, and not public Matrix. - **Mass-market secrecy for normal contacts → Signal**, ideally on a burner number. - **Community / group ops where the membership is already public → Matrix, self-hosted.** - **Always route over Tor or a trusted VPN** so the relay logs an exit, not your home IP. - **Compartmentalize by circle.** Don't let one messenger identity bridge your activist, financial, and personal graphs into one joinable cluster — the same rule as Week 2. ## Common mistakes - **Choosing by popularity.** The most-installed app is optimized for reach, not for holding the least about you. - **"It's encrypted, so I'm anonymous."** Encryption is the content; the graph is the metadata. Different problem, different tool. - **Using Matrix for a sensitive graph without self-hosting.** Federation is a feature for communities and a liability for secrecy. - **Anchoring a "private" messenger to your real phone number.** One KYC'd SIM undoes the best crypto in the app. - **One identity across all circles.** It re-joins the very graph you split up. ## See also - xmr.club listings: privacy messengers and no-KYC number sources — the practical tools for shrinking the envelope. - Adjacent OPSEC52 weeks: Week 14 — message metadata, Week 4 — the VPN/Tor stack, Week 2 — identity compartmentalization. *OPSEC52 is xmr.club's weekly OPSEC series. Series index: [/opsec](https://xmr.club/opsec).* *Curated by [Cyber Satoshi](https://x.com/xbtoshi)* ## Related - HTML: https://xmr.club/opsec/15-secure-messengers - Series index: https://xmr.club/opsec - Twin index: https://xmr.club/llm/opsec.txt