How it works

In one minute. You sign in with an identity you already control (an AT Protocol account, the same kind Bluesky uses). Every call and message is encrypted on your phone and can only be opened on the other person's phone; the servers in between pass along sealed envelopes they cannot read. Group chats work the same way, and no company's server is needed to run them: the members' phones hold the keys between them. A phone number on the network is tied to keys only you hold, so a carrier cannot hand it to a stranger. When the person you are calling is not on the network, the call crosses to the ordinary phone network through a gateway, and the app tells you that leg is not private.

ATSMS: encrypted messaging with no server in charge

Anyone on any app should be able to reach anyone on any other, privately, with no company in the middle. ATSMS is an open protocol for end-to-end encrypted messaging and calls between AT Protocol identities. Its defining goal is to be open the way email is open: any client that follows the protocol can reach any other, across independent operators, with no central or always-on server in the middle.

A protocol that must run without a privileged coordinator cannot adopt a design that requires one, so there is no server that puts messages in order, no delivery service and no privileged party. Members change a group whenever they like, and every device converges on the same keys from whatever order the network delivers.

Identity you already have, keys on every device

Your identity is your AT Protocol DID, did:plc or did:web, and your prekeys and per-device certificates are ordinary records in your personal data server. There is no ATSMS account to create. Each device holds its own key pair, so private keys can live in secure hardware and never move; adding a device, losing one or recovering from a compromise are all the same operation: a change to the group.

Old messages stay safe, and the group heals after a theft

Message keys come from a per-sender ratchet, a chain of keys that advances with every message, each discarded once used, so stealing keys today does not hand over yesterday's messages. Recovery runs the other way: re-keying the group tree reseeds every ratchet, and an attacker holding old material is locked out the moment each device processes the update.

Every message travels in a sealed envelope. The relay that stores and forwards it learns neither the sender nor the conversation; messages are padded into fixed-size buckets so length reveals little. What the relay does see: the connecting IP address, timing and volume. We do not defend against watching timing and volume over time (traffic analysis), and members of a group can see who added and removed whom.

Groups without a server, up to a point

A small group needs no infrastructure at all: each device delivers a sealed copy to each recipient, and the group exists because its members hold the keys. That costs the sender one upload per recipient device, which is nothing at ten devices and noticeable at fifty. We recommend the arrangement up to about 25 devices. Beyond that a group can add a group relay, one shared place the sender uploads to once, which still cannot read anything.

Single messages from organizations (“one-shots”)

A payment cleared, a prescription is ready, a new sign-in: one message from an organization you have no conversation with. Today those arrive by text or email, unencrypted and forgeable. ATSMS has a second kind of message for exactly this. A one-shot is sealed to the recipient, needs no session, and is signed with a key published under the sender's identity, so it cannot be forged and its sender cannot later deny it. Every ATSMS client must be able to send and receive one-shots, which makes them the cheapest way to start building on the protocol.

Built on published research

The group key agreement is a TypeScript port of BeeKEM, Ink & Switch's concurrent variant of TreeKEM, held to byte-for-byte agreement with the upstream Rust implementation by an automated oracle. The group management follows the decentralized continuous group key agreement work of Weidner, Kleppmann, Hugenroth and Beresford (CCS 2021), with p2panda's strong-remove semantics for removals that race other changes. We evaluated the IETF's MLS and chose not to use it, because MLS needs a delivery service to order commits and that requirement pushes a protocol toward a central party. The message format follows the IETF's MIMI work on interoperable content, which is still in progress. None of the beautiful part is ours, and any mistake in what we built on top belongs to us.

Reaching the network everyone still uses

Phone numbers are why this project exists and the hardest part of it. Encrypted messaging between people who already share a protocol is a solved problem; phone numbers are not. Most of the people you call are not on any new network, and the numbers themselves are administered by carriers and regulators, not by a protocol. The telephony layer sits on top of the messaging core.

Who owns this number?

A number on the network is bound to an identity by two signed records: the registrar attests that the number is in its custody for this identity, and the identity consents to that binding from its own data server. Either record missing means the number is an ordinary phone number. Because the holder's half requires the holder's keys, a fraudulent port-out at the carrier can move the number but cannot forge the binding: the number goes dark instead of being hijacked, which is the inverse of a SIM swap.

Is this call encrypted?

When a caller looks up a number and finds a live binding and a current device certificate, the call runs over ATSMS, encrypted end to end. When it does not, the call bridges through a Gateway Node to the ordinary phone network. The two are never silently interchanged: a client is required to show which kind of call it is, because the bridged leg crosses the ordinary phone network and carries that network's exposure.

Who runs what?

Two kinds of node. Relay Nodes store and forward sealed envelopes, hand out prekeys and set up calls. Anyone can run one; the reference implementation is a Cloudflare Worker. Gateway Nodes bridge to the phone network: they terminate calls and texts, register and port numbers, and carry the regulatory obligations that come with real phone numbers. They are run by operators, and which operators may vouch for numbers is governed by an accreditation process (see the operators page).

An AI assistant in front of your number

Any person or business on the network can put an AI assistant in front of their number to screen what comes in. The assistant has its own keys, and the link between an assistant and the person behind it is private to the operator that runs it, never published. The protocol provides the primitive: the runtime that answers a call from the phone network, talks to the caller and decides whether to ring you through. What the assistant says and how it decides is the operator's product.

Where the name Bourbon comes from

When we first announced the phone-number layer in March 2025 we called it the Bourbon Protocol, ahead of a white paper. The name is a joke we kept: the protocol most internet calling runs on is called SIP, and we like to sip bourbon. That work now ships as part of ATSMS, and Bourbon remains our informal name for the phone-number specification. The original introduction is still worth reading for the reasoning:Introducing The Bourbon Protocol.

Status, as of September 2026

Read the specificationsWhat we know is broken