AT Protocol made a specific bet: the account should belong to the person, not to the company whose app they happen to be using. Your DID is yours. Your posts live on a server you picked, and if you dislike the options you can run your own. That is unusual, and it is the reason a lot of us are here.
Private messaging never got the same treatment. Direct messages still live on somebody's server, usually in a form that server can read. Even the ones that are properly end-to-end encrypted still run on that company's infrastructure, on terms that can change without asking you. You can leave, but the conversations do not come with you, and hosting them yourself was never an option.
At 3NUM Labs we have been building ATSMS to close that gap. It is end-to-end encrypted messaging and calling that works the way the rest of AT Protocol works. We recently published the specifications, the code under an Apache-2.0 licence, along with a developer-focussed demo — the technical story is in the companion post. This post is about what it means for the rest of us.
To be clear about where things stand, the cryptography has not yet been through an independent security review, and the companion post is specific about what is and is not finished.
Email, oddly enough, is the best place to start explaining what ATSMS is.
Why Email Is the Right Comparison
Email has a property we have mostly stopped noticing. You pick a provider, or you run your own server — an option that nearly died out because the big mail providers grew so quick to reject unfamiliar servers as spammers, and one that projects like comail.at are now making real again. Your address is yours to hand out. You can write to anyone at any other provider, because everyone agreed on how mail moves, rather than because you both installed the same app.
Messaging works the other way around. You can reach the people who use the app you use. The company behind it decides who may talk to whom, what the rules are, and whether your account still exists next week. Even on AT Protocol, direct messages took this path rather than the open one the rest of the network is built on.
ATSMS moves messaging back to the email-like arrangement, with the privacy email never had. You reach somebody by looking up their identity, finding where they receive messages, and delivering there. No shared app required. The difference from email is that nothing along the way can read the contents.
That is not an analogy, incidentally. One of the delivery options ATSMS supports is SMTP, the email protocol itself, used as a carrier for encrypted payloads that no mail server can open.
What You Get
Your identity is the one you already have. No new account, no phone number handed over, no separate username. Each of your devices proves it belongs to you by publishing a credential into your own repository. Nobody issues it and nobody approves it. Publishing it is the permission.
You choose where your messages arrive. With AT protocol, your posts live on a PDS you picked or one you run. In the same way, with ATSMS your messages arrive at an inbox you picked or one you run. The software is open and small. If you would rather someone else operate it, use a provider. If you would rather trust nobody, do not. The protocol behaves the same either way.
The middle cannot read anything. Messages are encrypted on your device and decrypted on the other person's. Everything in between holds sealed envelopes. A server carrying your message sees an address, a time, and a size rounded into buckets. It does not see the contents, and it does not see who sent them.
It does see some things. It sees the network address that connects to it, and it sees when traffic arrives and roughly how much. Somebody watching that pattern for long enough learns something, and we do not defend against it.
Several devices, properly. Add a laptop or a tablet by authorizing it from a device you already have. Your existing conversations include it from that point on. History is a separate question, because no server holds a readable copy to hand over. An app can sync it between your own devices if it wants to, and that choice belongs to the app rather than to the protocol.
Groups and calls, not only text. Encrypted group conversations, and encrypted voice and video calls between two people, with call setup running over the same encrypted channel as the messages. Calls to a whole group are coming; today they are one to one. When somebody leaves a group or is removed, the keys change immediately, so they cannot read what comes afterward, even if they run modified software.
Your Group Doesn't Need a Server
For an ordinary group, a few colleagues, a band, a household, there is no group infrastructure at all. Nobody runs a server for the group. There is nothing to administer and nothing to pay for. Every device sends to every other member's inbox, the same inbox they already use, and the group exists because its members hold the keys. There is nothing to shut down.
The cost of that arrangement is that your phone does all the delivery itself, one sealed copy per device. For a family thread or a group of friends that is nothing. Past a dozen or so people it starts to be real work for the sending phone, and that — not any rule in the protocol — is what sets the comfortable size for a server-free group.
For larger groups, the design adds a group relay, one shared place where a message is left once and collected by everyone, which takes that work off the sender entirely. The relay still cannot read anything, and a group that uses one can move to a different relay later without disturbing the conversation. (The relay is designed and published as a proposal, not yet built — today the working answer is the server-free arrangement.)
A group relay is an ordinary service with a small job, so it can be run by a hosting provider, a community, a university department, one member with a spare machine or offered by the app itself. Nothing about it is privileged, and nothing about it is proprietary.
What We Are Not Building
ATSMS is not a Discord or Telegram replacement. Thousands of people in one room, with searchable history and newcomers scrolling back through months of conversation, needs a server that holds everything. That is a reasonable thing to want and other people build it well.
ATSMS is for conversations between people who know each other — a dozen or so today, more once group relays exist — where nobody in the middle can read the messages or end the conversation.
What You Can Do
The demo exists so developers can kick the tires, and it is rough in the ways early software is rough — if you are curious it will happily sign you in with the account you already have, but it is not yet something to move your group chat to.
Expect more from the apps you already use. Ask whether your private messages are really private, and what happens to your conversations if you ever leave. Protocols like this one spread because people ask those questions out loud — the apps that adopt it will be the ones whose users wanted it. And if you know someone building on AT Protocol, send this to them; the people who can act on it are a small community, and word of mouth is how it reaches them.
The companion post goes deeper — how a group agrees on keys with nobody in charge, what the servers actually learn, and why we picked a design that does not need a coordinator.
ATSMS Group Chat: End-to-End Encryption Without the Lock-In
Private group messaging that belongs to you, not to an app — built on the AT Protocol identity you already have. A proof of concept, published with its specifications, its code, and its open questions.
What Comes Next
Messaging is where this starts, not where it ends. Everything this post described — an identity you own, sealed envelopes, nobody in the middle — applies just as well to the oldest network we all still use. What we are building on it will blow your mind.