How your account moves between phones without going through our server

You buy a new phone. You want your messaging app on it, with your conversations, contacts, groups, all of it.

If you use WhatsApp, the path is: install on the new phone → enter your phone number → receive SMS → the app pulls your account history (and increasingly your messages, even though they're end-to-end encrypted) from Meta's servers. Your data round-trips through a third party in the process — encrypted on the wire, but the metadata (when, how big, which account) is exposed, and the encrypted blob itself sits in their cloud for as long as it takes you to set up.

If you use Signal, the path is gentler — link your new phone via QR scan, the new device authenticates with the existing one over Signal's relay. Old messages don't transfer by default; if you want them, you go through an explicit backup-and-restore using a separately-generated passphrase.

BlindPost works differently from both. Your new phone and your old phone connect directly over local Wi-Fi, set up a sealed end-to-end-encrypted channel, and transfer your account material between themselves. Our server never sees the migration happen. Nothing about your identity, keys, or message history transits our infrastructure during the move.

Here's how that works.

The path the data takes

1. Same network. Both phones need to be on the same local network — your home Wi-Fi, your phone's hotspot, anything where the two devices can reach each other directly. (No, you can't migrate across the internet. Migration is designed as a hand-to-hand operation: you have both phones physically present.)
2. QR-coded handshake. The new phone shows a screen with a QR code containing one-time setup data. The old phone scans it. The two devices use what they just exchanged to establish a sealed end-to-end-encrypted channel between themselves — keys for this transfer only, separate from your account keys, used once and discarded.
3. Preflight check. Before any account material moves, the two clients walk through a short series of verifications — confirming they can really see each other, that no third party has wedged into the channel, that the new device is in a state ready to receive. If anything looks off, migration aborts before any data moves.
4. Sealed transfer. Your identity keys, current and historical prekeys, group keys for every group you're in, and your local message history all flow over this point-to-point channel from the old phone to the new one. Encrypted end-to-end with the just-exchanged transfer keys. None of it touches the public internet beyond the local network segment.
5. Verify and finalize. The new phone verifies that what arrived matches what was supposed to arrive, marks itself as the active device for your account, and the old phone offers to wipe itself (or stay as a secondary device — your call).

The whole thing takes a few seconds for a small account, a couple of minutes for one with years of message history and assets.

What our server sees during the migration

Approximately nothing.

We don't see the QR-code contents (they live only on the two phones during the brief moment of handshake). We don't see the sealed channel between the devices (it's a local TCP connection that never reaches us). We don't see what was transferred (everything moves over that local channel, never up to our infrastructure). We don't see whether a migration happened — the new device just shows up on its next connection with the same identity key as before, indistinguishable to us from "the existing device after a software update."

Compared to the cloud-backup model: in WhatsApp's case, even with E2EE backup turned on, Meta's server holds an encrypted blob of your message history. They know how big it is, when you uploaded it, and that you have one. The blob is decryptable only with your key, but its existence and metadata are exposed. In BlindPost's case, no such blob exists on our side. The bytes moved directly between two devices you control.

What this costs

Two real constraints:

• You must have both phones physically present. "Lost my old phone, want my history on a new one" — there's nothing we can do. The migration channel is between two devices, both of which need to be online and reachable. If your old phone is broken / lost / stolen, your only recovery is the 12-word mnemonic, which restores your identity but not your historical messages (since those messages were only ever on the old phone, never on our server).
• You need to do it before retiring the old phone. This is the small but real "no cloud backup" friction. We do not (and architecturally cannot) restore messages from a backup we never made. The same property that buys you privacy from us also means you cannot lazy-migrate.

We've heard the request — "can't you offer optional encrypted cloud backup, opt-in only?" — and we keep declining. Optional features tend to become the default through small UX nudges, and the moment cloud backup exists at all, the data structure to support it has to exist server-side. The whole privacy-by-architecture story collapses to privacy-by-promise the moment we add that table. We'd rather make migration a hand-to-hand operation that you do consciously, once, on your own schedule.

What you get

A migration that you can see happen — both phones in front of you, both screens showing progress, both verifying each other before anything moves. No third party sees the operation; no breach can recover what didn't pass through.

Most of the value of the privacy stack we've built in other posts would be undermined by a cloud backup that leaks the same information through a side channel. Migration without our server is what keeps the architecture honest.