How it works

ATSMS: encrypted messaging with no server in charge

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.

That openness is the constraint everything else answers to. A protocol that must run without a privileged coordinator cannot adopt a design that requires one, so there is no sequencer, 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.

Forward secrecy and recovery from compromise

Message keys come from a per-sender ratchet that advances with every message and is 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. The rules for deleting old key material are specified and not yet enforced in code; it is on the known-issues list.

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 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. The group relay is a published proposal, not a finished part of the protocol.

One-shots: a message that is not a conversation

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

Encrypted messaging between people who already share a protocol is a solved problem. Phone numbers are the hard part: 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. Today the lookup trusts a single registrar and the data server it reads from; verifiable lookups that check the repository proofs are designed and not built.

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 legacy 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 Nodesbridge 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 agent in front of the number

An identity can put an AI agent in front of itself to screen what comes in. The agent is its own identity with its own keys, and the link between an agent 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 agent says and how it decides is the operator's product. Inbound calls from the phone network answered this way have been live since September 2026.

A word about the name

The telephony layer is specified separately from the messaging core. When we first announced it in March 2025 we gave the design its own name, the Bourbon Protocol, ahead of a white paper. The work has since shipped under the ATSMS name, and "Bourbon" remains our informal name for the telephony specification. The introduction is still worth reading for the reasoning:Introducing The Bourbon Protocol.

Status, as of September 2026

Read the specificationsWhat we know is broken