You type "on my way," hit send, and a second later it is on your friend's phone. In between sits a server. How much does that server have to know (about you, about your friend, about the fact that the two of you are talking at all) for the message to arrive? The answer we fought for is: almost nothing.
This is the story of the piece of the system that carries messages: the relay. It is the entry point to a series, and each hard sub-problem gets its own deep dive that this article links out to as we go. If you have taken a data structures course and remember what a "hash," a "public key," and a "server" are, you have enough to follow along. We will meet the specialized cryptography exactly when we need it and never before.
Two phones almost never want to talk at the same instant. Yours is awake; your friend's is in a pocket, screen dark, the app suspended by iOS to save battery.
So every messenger puts a server in the middle. You hand it a message, it holds or forwards that message, and when your friend's phone is reachable the message lands.
That middle server is the relay, and it is the most privacy-sensitive machine in the whole system, not because of what is in the messages, but because of what surrounds them.
Here is the uncomfortable fact. You can encrypt message content end to end, so that only the two phones hold the keys and the relay sees nothing but ciphertext: the scrambled bytes of an encrypted message. That part is table stakes, and we do it. And the relay can still betray you completely.
Because even with perfect content encryption, the naive relay learns who is talking to whom, how often, at what times, and in what pattern.
That is a social graph, and a social graph is often more damaging than the words. "We don't have your messages" is a sentence a surveillance-friendly service can say with a straight face while handing over everything that actually matters.
So let us be precise about what we want. When Alice sends a message through the relay to Bob, the relay must not learn:
And two things the relay still must do, which is what makes this hard rather than trivial:
Plus one clause that reshaped every decision, exactly as it did in our Contact Discovery work: it has to hold forever. A recording of who-talked-to-whom does not expire, and neither does a signature that proves you said something. An adversary can record the encrypted traffic today and wait (for a quantum computer, or just for a subpoena) and try to break it in fifteen years. So every layer of the wrapping must resist quantum attack. And, as we will see, every authenticator (every proof that a message is genuine) must be deniable.
The obvious design is a mailbox: the relay keeps a table, one row per undelivered message,
(recipient, sender, timestamp, ciphertext), and Bob's phone downloads its rows when it
wakes. Encrypt the ciphertext column and you might feel done.
You are not close to done.
That table is the social graph: in a database, sorted and indexed for convenient querying, retained until delivery and often long after. A breach dumps it. A subpoena compels it. An honest-but-curious operator (one who follows the rules but reads everything the rules let him see) mines it.
The columns you did not encrypt (who, to whom, when, how big, how often) are precisely the metadata that de-anonymizes people, and no amount of content encryption touches them.
Signal's own research and a decade of "metadata is the message" reporting say the same thing: the envelope leaks more than the letter.
Everything in this series is a reaction to one of those leaks. The rest of this article is the map.
The design principle is blunt: the relay should be a dumb pipe that learns as close to nothing as the laws of networking allow. We get there by wrapping the message in layers, peeling off one thing the relay is not allowed to know at a time, until what is left on the outside is the bare minimum needed to move bytes to the right phone.
A useful mental model is a paranoid postal system:
Each of those is a sub-problem, and each turned into its own piece of engineering:
| What the relay must not learn | Why it's hard | Deep dive |
|---|---|---|
| The message content | the baseline everything else assumes | The End-to-End Layer |
| Who sent it | the relay must still route and authorize the message | Sealed Sender |
| That two chats are the same person | a stable pseudonym silently clusters a sender's whole life | Sender Unlinkability |
| The message kind and precise time | the relay must read something to know how to wake a phone | The Envelope |
| That it held the message at all | a durable mailbox is a metadata honeypot | Ephemeral Delivery |
| Which conversation you are reading | the act of pulling your mail leaks which box you checked | Oblivious Pull |
| The graph, when it wakes your phone | the only wake channel runs through Apple | Waking a Sleeping Phone |
| …while still blocking floods | we made the sender invisible, so who do we throttle? | Anonymous Admission |
| …forever, and un-provably | a signature is a portable, permanent confession | Deniability |
The rest of the series is the machinery underneath. But two constraints cut across all of it, so they come first.
Post-quantum. A social graph is exactly the kind of long-lived secret that "harvest now, decrypt later" is designed to steal: record the traffic today, break the wrapping in 2035, reconstruct fifteen years of who-knew-whom retroactively.
So, as a hard rule (the same one the discovery path follows), the relay's cryptography avoids anything a quantum computer breaks.
In practice that means lattices: problems about finding a short, well-hidden vector in a regular grid of points in a few hundred dimensions. They give the best-understood post-quantum assumptions, and the sibling series builds them up from nothing in Lattice Foundations.
Four places it lands. Key agreement (the step where two phones settle on a shared secret key) is PQXDH, Signal's key exchange with a lattice lock added beside the classical one. Two of the wrappers we will meet later (the seal on group-membership messages and the seal on push wake-ups) use X-Wing, a hybrid that runs a lattice KEM, ML-KEM-768, together with the classical curve X25519, so an attacker has to break both.
(A KEM, a key encapsulation mechanism, hands the sender a fresh shared secret plus a ciphertext that only the private-key holder can turn back into that secret.) Identity signatures are doubled the same way: Ed25519 + ML-DSA-65, one classical and one lattice signature over the same bytes. And the admission token is a lattice VOPRF, a verifiable oblivious pseudorandom function: a keyed secret function only the mint can evaluate, applied to an input the mint never gets to see, with a proof that it used the right secret.
Where we still lean on a classical primitive, we say so out loud and explain why the residual is acceptable.
Deniability. This one is specific to a messenger and easy to miss.
A digital signature is not just authentication. It is transferable proof. If Alice signs each message with her long-term key, then anyone who later gets the transcript (a breach, a seized phone, a hostile recipient) holds a mathematical certificate that Alice, and only Alice, wrote those words, and can prove it to a third party who was not there.
Face-to-face conversation has never worked that way. You can always deny what you said, and we want the digital version to keep that property.
Worse, this is a harvest-now-judge-later threat: a signature recorded today stays a valid proof forever, even against a future quantum "judge."
So the relay's authenticators are deliberately not signatures where they do not have to be. They are deniable MACs: message authentication codes keyed by a secret the two parties share, which makes them authenticators the recipient could have produced themselves. They convince Bob the message is real while proving nothing to anyone else.
That is Deniability, and it is why several places you would expect a signature have a shared-key MAC instead.
A quick tour of the layers, each linking to its full treatment.
Content, and the layer we build on. Underneath everything, the message body is encrypted with libsignal, Signal's open-source encryption library: PQXDH to set up a session, the Double Ratchet to give every message its own key, and SPQR, a post-quantum ratchet, so even the steady-state stream resists a future quantum computer.
This is the one part we consume rather than invent (it is Signal's, and excellent), but we add a fail-closed guard that refuses to send or accept a steady-state frame not actually carrying the post-quantum ratchet. See The End-to-End Layer.
Who sent it. The relay has to check that a message comes from a real, non-banned user
before it spends resources delivering it, but it must do that without learning the user's
identity. The trick is sealed sender: the sender's identity and their signed
certificate ride inside the encrypted payload, and the relay sees only an opaque
16-byte ticket, the cert_id. See Sealed Sender.
Linking chats. A ticket that stays the same across all of Alice's conversations is still a pseudonym: the relay can cluster "everything ticket #7 ever sent" into one person's social life. So Alice mints a different certificate per conversation, and the relay loses the thread between her chats. See Sender Unlinkability.
Kind and timing. The relay cannot be completely blind. To decide whether to ring a phone like an incoming call or nudge it silently in the background, it has to read how urgent a message is.
We give it the absolute minimum: a coarse WakeClass with six values, while the precise message type (one of a couple of dozen fine-grained kinds, reaction, post, huddle turn, sync) stays sealed inside.
Crucially, the recipient re-derives the class from the sealed type and rejects a mismatch. So a lying relay can only degrade a notification, which is detectable, never learn the kind. See The Envelope.
Holding it. There is no durable mailbox. The relay is publish/subscribe: it hands bytes to whoever is listening at that moment, like a radio broadcast, rather than storing mail. A message with no live subscriber is simply not queued for that device. The one deliberate exception is a sixty-second window of opaque, still-sealed ciphertext, kept so a phone that was away can fetch what it missed without telling the relay which conversation it is asking about. Durability lives entirely in the sender's outbox, and a message is cleared only when Bob's phone acknowledges it. See Ephemeral Delivery.
Reading it back. When Bob reconnects and pulls whatever he missed, naive polling would tell the relay which conversation had new mail. A short windowed pool served by Private Information Retrieval (PIR) lets him fetch his messages without the relay learning which he asked for. PIR is a technique that lets a client fetch one item from a server without the server ever learning which item, built on the same lattice construction as the discovery path. See Oblivious Pull.
Waking him. If Bob is offline we have to ring his doorbell, and iOS offers exactly one doorbell: Apple Push.
That is a real exposure. A push token is the per-device ticket Apple uses to route notifications. Whoever presents Bob's token to Apple, and also holds the directory mapping tokens to accounts, can join Bob's phone-linked identity to his message traffic.
We split that path into a blind registry and a "decrypt one wake and forget" sender, and seal each wake to an attested key: one that arrives with a signed statement of exactly which software is holding it.
Apple itself remains a floor we disclose rather than pretend away. See Waking a Sleeping Phone.
Paying for it. Now the paradox: we hid the sender so thoroughly that we cannot throttle them by identity. The resolution is to move the rate limit upstream (a budgeted, authenticated mint hands out single-use admission tokens) and give the relay a token it cannot link back to the mint, so it can only count spends, never identify a spender. (That unlinkability is computational rather than unconditional: it rests on a hard math problem, one chosen to survive quantum attack.) See Anonymous Admission, which is precise about the difference and why the trade was taken.
Put together, one message travels a single, uniform path. As with the discovery work, we deliberately collapsed early alternatives into one way of doing things (a security system with four code paths has four times the attack surface):
{ recipient routing address, coarse WakeClass, fuzzy timestamp, cert ticket, one admission token }.At no step does the relay hold a durable mailbox, see an identity, learn a message kind, link two conversations from what an envelope carries, or produce anything that could later prove who said what. What it does learn (a rotating routing address, a coarse class, a fuzzy time, a per-conversation pseudonym, and a spent anonymous token) is the residue we could not remove without breaking delivery, and each article that follows is honest about exactly that residue.
One piece of that residue comes from the connection rather than the envelope, and is worth naming here because no single envelope reveals it.
A device opens one socket (one live network connection) and subscribes to its whole set of current addresses at once, so the relay learns that those addresses share a subscriber. It learns no identity and no contents, and the addresses themselves rotate, but the grouping is real.
That is exactly why the oblivious pull path in Oblivious Pull exists as the stronger alternative for a phone that would rather not hold a socket at all.