What Makes a Messenger Metadata-Resistant?

A metadata resistant messenger is one that hides who you talk to, when, and from where — not just what your messages say. Most "encrypted" apps lock the message body but leave a detailed trail around it, and that trail is often more revealing than the words themselves.

If you want to judge an app on real privacy rather than marketing, you need a checklist you can apply yourself. This guide gives you one: five properties that separate a genuinely metadata-resistant messenger from an app that merely encrypts content.

Why metadata is the real privacy problem

Encryption protects the contents of a conversation. Metadata is everything else: which accounts exchanged messages, at what times, how often, from which IP addresses and locations, and on what devices. Michael Hayden, a former director of the NSA and the CIA, famously summed up its intelligence value — "we kill people based on metadata."

The problem is that content encryption and metadata protection are separate battles, and many popular apps win the first while barely fighting the second. Your message may be unreadable, yet a server, a network observer, or a subpoena can still reconstruct your entire social graph. If you want the deeper background, see our pillar guide to the encrypted messenger, and the companion explainer on messaging metadata.

The metadata-resistance checklist

Run any messenger through these five questions. The more it fails, the more of your life it leaks — regardless of how strong its encryption is.

1. No identifier at sign-up

The first metadata leak happens before you send a single message. If registration demands a phone number, that number ties your "anonymous" account to your real identity, your SIM, your carrier records, and often your contact graph.

Ask: can I create an account with no phone number and no email? If the answer is no, the app knows who you are from minute one, and so does anyone who can compel the provider to hand over records.

2. Sealed sender and no server-side account

Even with strong encryption, a relay that runs a per-user account can log who sent what to whom. Two techniques reduce this:

• Sealed sender removes the sender's identity from the message envelope, so the server routing the message can't easily see who it came from.
• No account model goes further: there is no server-side profile to correlate against in the first place. Your identity lives on your device as a keypair, not as a row in the provider's database.

Ask: does the server have an account for me that ties messages together? The less the relay knows, the less it can log, leak, or be forced to reveal. Our deep dive on sealed sender covers how the envelope trick works and where its limits are.

3. IP address and network hiding

Your IP address is metadata too. It reveals your rough location, your ISP, and — correlated over time — your movements. Content encryption does nothing to hide it; the server you connect to still sees the address the packets came from.

Ask: does the app hide my IP from the server and from network observers by default? True network-layer privacy usually means routing traffic through something like Tor or an onion network, so the destination sees an exit relay rather than you. "By default" matters: an option buried in settings that most users never enable protects almost no one.

4. A no-logs relay that never sees plaintext

A relay can be honest about content and still keep damaging records: delivery timestamps, sender/recipient pairs, connection logs. The strongest posture is a relay that stores only sealed ciphertext and holds no keys, no plaintext, and no identity.

Ask: what does the server actually store, and can it read any of it? If the operator can't decrypt your messages and doesn't keep a routing ledger, a breach or a legal demand yields very little.

5. Short message TTL and delete-after-delivery

Data that no longer exists can't be subpoenaed, leaked, or mined. A metadata-resistant messenger keeps undelivered messages only as long as needed and deletes them once they arrive.

Ask: how long does the server hold my messages, and what happens after delivery? A short maximum time-to-live plus deletion on delivery (acknowledgement-gated, so nothing is dropped before it's received) dramatically shrinks the window in which your data is exposed.

How the popular apps compare

No mainstream messenger checks every box, and the table below is a fair, high-level snapshot — not a scorecard of overall quality. Each app makes different trade-offs.

Messenger	Requires phone number?	Hides your IP from the server by default?	Message content E2EE by default?
Signal	Yes	No	Yes
WhatsApp	Yes	No	Yes
Telegram	Yes	No	No — only opt-in Secret Chats
Session	No	Yes (onion-routed)	Yes
Threema	No (not required)	No	Yes
Graphite	No	Yes (Tor by default)	Yes

A few honest notes so you can read the table fairly:

• Signal is strong on content: E2EE by default, open-source, and it minimises metadata with sealed sender and has adopted post-quantum key agreement (PQXDH). It still requires a phone number to register, though usernames now let you hide that number from other users.
• WhatsApp encrypts message content by default with the Signal Protocol, but it's owned by Meta, ties you to a phone number, and collects metadata; cloud backups aren't end-to-end encrypted unless you turn on encrypted backups.
• Telegram should not be called "encrypted by default": its cloud chats are not end-to-end encrypted and Telegram can access them. Only opt-in one-to-one Secret Chats are E2EE, and it requires a phone number.
• Session uses no phone number and onion routing, which is why it scores well on identifier and IP columns.
• Threema is a paid, Swiss app with open-source clients that doesn't require a phone number, but it doesn't route your traffic to hide your IP by default.

If your threat model is metadata rather than only content, the phone-number and IP columns matter as much as the encryption column.

Where Graphite fits

Graphite was built specifically to pass this checklist rather than only the encryption test.

• No identifier. There's no phone number and no email. Your identity is a 12-word recovery phrase generated on your device, and there is no account on the server to tie messages together.
• Sealed, no-account delivery. Messages are protected with NaCl/libsodium sealed boxes, plus a hybrid post-quantum layer (ML-KEM-768) and Signal-style double-ratchet forward secrecy. The relay never sees your plaintext, your keys, or your recovery phrase.
• IP hiding by default. Graphite runs over Tor by default, fail-closed, connecting to a bundled hidden service so the network and the relay don't see your real IP. (Signaling and messages travel over Tor; real-time call media uses peer-to-peer DTLS-SRTP, and on mobile calls are routed so the other person doesn't see your IP.)
• No-logs relay. The relay stores only sealed ciphertext, holds it for a 7-day maximum, and deletes it after delivery (acknowledgement-gated).
• Everything encrypted. Voice and video calls use DTLS-SRTP; on-device AI search means nothing is uploaded to find an old message; group chats and file sharing are encrypted too.

It runs on Windows (a portable .exe with bundled Tor), Android (a sideloaded APK that works on GrapheneOS and de-Googled phones with no Google Play Services), and as a web app.

The takeaway

Encryption answers "can someone read my messages?" Metadata resistance answers the harder question: "can someone see that I sent them at all, to whom, and from where?" Use the five-point checklist — no identifier, sealed/no-account delivery, IP hiding, a no-logs relay, and short TTL — on any app before you trust it with a sensitive conversation.

Graphite is free and in public beta (v1.13.25) on Windows, Android, and the web — no phone number, no email, and no logs. Try it at graphite.chat.