Who sees the envelope: metadata in Signal, SimpleX, Session and XMPP compared
End-to-end encryption answers one question — can anyone read this message as it travels — and says nothing about the quieter one that matters just as much: who can see that a message happened at all. Delivery metadata such as connection times, IP addresses, identifiers and contact patterns is never encrypted, because something has to stay readable for the traffic to be routed.
What metadata covers
Content encryption hides what is said. It does not hide that a device contacted a service at a given moment, from a given network, and exchanged a payload of a given size. Timing and volume alone can sketch who talks to whom and when, which is why each messenger's architectural choices about metadata matter as much as its cipher suite.Signal: sealed sender and minimal retention
Signal keeps server-side storage to a minimum and, since 2018, uses sealed sender to strip the sender's identity from the outside of every message — the project's own comparison is mail with "a blank space where the 'from' address used to be", deliverable knowing only the destination. The same post admits the limits: resistance to "traffic correlation via timing attacks and IP addresses" remains ongoing work, and a device using Signal still announces its connection to Signal's infrastructure. What Signal retains is documented less by marketing than by legal disclosures. Its government requests page publishes the transcripts of demands it receives; answering a 2016 grand jury subpoena, the company reported that the only information it could produce was the account registration date and the date of the user's last connection. Requests answered in 2021 and after another grand jury subpoena in March 2026 repeat the theme that the data simply does not exist on Signal's servers. What remains is the residue any client-server design has: when you connected, and from where. One structural identifier remains: Signal accounts are created against a phone number, though usernames now keep it out of other users' contact lists. That ties every account to something in the real world, which matters when the holder must not be linked to a person.SimpleX: no user identifiers on the network
SimpleX attacks the identifier problem directly. Instead of accounts, it relays messages through per-contact message queues whose addresses are the only thing a server knows. The project states that "SimpleX Chat has no user identifiers visible to the network", with profiles, contacts and messages stored only on client devices. A conversation typically runs through two different relays, one per direction, so no single operator sees traffic flowing both ways. Independent scrutiny exists: a Trail of Bits code audit announced in November 2022 found two medium and two low severity issues in the cryptography and networking library, none undermining the no-identifiers model. What SimpleX servers do see is the queue address and the connection to it — a large part of why the project has since invested in private routing to shield senders' IP addresses from relay operators. As with any relay design, the margin also depends on network size: a queue on a little-used server is easier to correlate than one buried in busy traffic.Session: onion requests over its own network
Session removes phone numbers and email from account creation: an account is a freshly generated random ID with a recovery seed. Messages travel through its decentralised network as onion requests, layered so that, in the project's words, "no single server ever knows a message's origin and destination". Delivery runs through swarms of five to seven nodes holding encrypted messages until collected. The documentation even claims this makes it "impossible for Session to track users' IP addresses" — an absolute statement that deserves caution, since a smaller self-operated network leans on the integrity of its nodes.XMPP with OMEMO: encryption without metadata promises
XMPP is the federated case. The OMEMO standard (XEP-0384) brings Signal-style double-ratchet encryption to XMPP with multi-device support, treating servers as untrusted for content. The specification is honest about the boundary: it does not protect against "metadata and traffic analysis". On a federated network, who talks to whom is visible to the servers hosting the accounts and to anything on the federation path between them. Choosing a provider is therefore a metadata decision as much as an availability one — content encryption is standardised, metadata protection depends on the operator.What none of them remove
The comparison stays honest only if it ends with what all four share:- Signal: the service sees connection times and IP addresses, and registration is phone-number based; sealed sender hides the sender's identity, and published disclosures show the produced data as registration and last-connection dates.
- SimpleX: relays see queue addresses and connections to them; profiles and messages stay on devices, with no account identifiers at the network level.
- Session: random account IDs, onion-request routing that hides origin and destination from individual nodes, encrypted messages held temporarily in node swarms.
- XMPP with OMEMO: content encrypted end-to-end, but servers and federation paths see who communicates with whom and when.
- All four: an ISP or local network still sees that a device talks to the service — or to Tor, if tunnelled — and timing correlation remains open everywhere.