Modern end-to-end encrypted messaging is built in layers, and the layers are easy to confuse. It helps to separate the three that matter here. X3DH is how two devices agree on a first shared secret, even when one of them is offline. The Double Ratchet is how those two devices then derive a new key for every message so that a single compromised key does not unlock the whole history. Both of those describe a single link between exactly two devices.
Sesame is the layer above them. It answers a question the other two do not touch: when a human being can log in from several devices at once, how does the sending app know which encrypted links exist, keep them current as devices come and go, and make sure a message reaches every one of the recipient's devices and none of the wrong ones. It was published by the same group behind the Signal Protocol as a companion specification, and while it is less famous than the ratchet, nothing multi-device works without something like it.
Users, devices, and why the distinction matters
The mental model Sesame introduces is a strict separation between a user and a device. A user is the person and their long-term identity. A device is one physical installation of the app, each with its own key material. Encryption does not happen between users. It happens between devices. When you send an encrypted message to a friend who has three devices, your app is really running three separate encrypted sessions, one to each of their devices, plus sessions to your own other devices so your sent message appears there too.
A single message you type is encrypted once per recipient device and once per one of your own other devices. Send a note to a friend with three devices while you have two, and your app quietly produces encryptions for four device sessions, not one.
This is why encrypted messengers do not let you simply copy an account onto a new phone the way you would restore a photo backup. Each device is a distinct cryptographic identity. The system has to know the full roster of a user's devices, and that roster changes: people add tablets, wipe phones, get logged out, replace hardware. Sesame is the bookkeeping that keeps this roster and the sessions attached to it correct.
What Sesame actually tracks
Underneath, Sesame maintains a structured record on each device. For every user you communicate with, it stores the set of that user's known devices. For every one of those devices, it stores the state of the encrypted session with it, if one has been established. That state is the Double Ratchet session. Sesame does not do the encrypting itself. It decides which session objects to hand a message to, creates new ones when a device appears, and retires ones that have gone stale.
The design pays close attention to a messy reality: two devices can try to start a session with each other at the same time, or a device can receive a message encrypted to an old session it has already replaced. Naively, either situation causes a device to try decrypting with the wrong keys and fail, which shows up to users as the dreaded undecryptable message. Sesame handles these races explicitly, with rules for which session wins when duplicates appear and how a device recovers when it receives traffic for a session it no longer holds.
Adding and removing a device
When you link a new device, it generates its own keys and publishes its own set of one-time prekeys to the server, exactly as a brand-new account would. The next time any of your contacts sends you a message, their Sesame layer notices your device list has grown, fetches the new device's keys, runs X3DH to establish a fresh session with it, and starts including it in the fan-out. You do not have to move any secret from an old device to the new one. The new device simply becomes another endpoint that others open sessions with.
Removal works the same way in reverse. When a device disappears from a user's list, Sesame stops encrypting to it and tears down the session. This has a real security consequence. Because each device is its own endpoint, revoking one does not expose the others, and a device that has been removed cannot silently keep receiving new messages. The roster is the access-control list.
The Double Ratchet protects a conversation. Sesame protects the idea that a conversation belongs to people, not devices, while never letting the encryption forget that devices are the only things that actually hold keys.
Sesame is not group messaging
It is worth drawing a line here, because the fan-out to multiple devices looks superficially like sending to a group. They are different problems. Sesame handles the several devices belonging to one user. Group messaging handles many users, each with their own several devices, and it needs its own machinery to stay efficient as the group grows. Some systems solve that with sender keys, and others with a purpose-built group protocol like MLS (RFC 9420). Sesame sits underneath all of them as the per-user device layer.
| Layer | Problem it solves |
|---|---|
| X3DH | Two devices agree on a first shared secret, even if one is offline |
| Double Ratchet | Fresh keys per message between two devices, so one leak does not unlock the rest |
| Sesame | Tracks a user's set of devices and their sessions; routes each message to the right ones |
| Sender keys / MLS | Efficient encryption to many users at once in a group |
Why any of this matters to you
Sesame is invisible when it works, which is most of the time, and painfully visible when it does not. If you have ever seen a chat app show a message it could not decrypt, or ask you to re-verify a contact after they set up a new phone, you were watching the device-and-session bookkeeping being reconciled. Those moments are not encryption breaking. They are the roster changing, and the system deciding whether to trust the change.
That last point is the one worth keeping. A multi-device encrypted messenger is only as trustworthy as its handling of the device list, because the device list is the set of endpoints that can read your messages. A well-built app makes device changes noticeable rather than silent, so a device added without your knowledge is something you can catch. When you evaluate a secure messenger, ask not only how it encrypts, but how it tells you when the set of devices reading your conversation has changed. Haven, like other MLS-based systems, treats that roster as a first-class part of the security model rather than an afterthought.