Introducing ATSMS

ATSMS: Building Decentralized End-to-End Encrypted Messaging on AT Protocol

Today, I'm super excited to introduce AT Secure Messaging Service (ATSMS): a decentralized, end-to-end encrypted messaging system built natively on AT Protocol. It's not another app competing for space on your phone—it's a foundation for making all messaging truly private, portable, and permanent.

The Message Monopoly Problem

Every morning, billions of people wake up and check their messages across a fragmented landscape of apps. WhatsApp for family. Discord for gaming. Slack for work. Each one a walled garden, each one holding conversations hostage. Switch platforms? Your message history vanishes. Company changes terms? Accept or lose access. Server goes down? Wait and hope.

Why Now? The AT Protocol Opportunity

AT Protocol has quietly solved one of the hardest problems in decentralized systems: portable identity. Your AT Protocol DID isn't tied to any single server or company—it's yours, cryptographically proven and universally verifiable. ATSMS extends this breakthrough to private messaging.

Instead of building yet another centralized service with promises to "open up someday," ATSMS launches as an open protocol from day one. This initial release focuses on achieving feature parity with Bluesky's existing DMs while laying the groundwork for something much bigger: a truly decentralized messaging network that could become the WhatsApp of the AT Protocol ecosystem.

How ATSMS Works: A Technical Deep Dive

ATSMS merges battle-tested cryptography with modern decentralized identity. Here's how we made the impossible practical:

Identity and Encryption: Your Keys, Your Control

At the heart of ATSMS lies a simple but powerful principle: your encryption identity is your AT Protocol DID, not your handle. Each device generates its own unique public/private key pair, encoding the public key in an X.509 certificate. The private key never leaves your device—stored locally in browser storage for our web prototype, or in secure device storage for native apps. The public certificate gets published to your PDS under the at.atsms.x509 lexicon, making it discoverable by anyone who wants to send you an encrypted message.

When you send a message, ATSMS encrypts it for each of the recipient's registered devices. Ed25519/X25519+AEAD will be used at launch, RSA/RSA-OAEP was used to expedite our prototype. Only those devices can decrypt the message. Every message also carries a cryptographic signature, proving who it came from without exposing any unencrypted sender information—a critical privacy feature missing from traditional email.

Message Routing: Leveraging 50 Years of Infrastructure

Here's where ATSMS gets clever. Instead of reinventing message transport, we leverage SMTP—the protocol that already delivers 300 billion emails daily across every server, provider, and country on Earth. But we're not trying to be backward compatible with legacy email encryption. We use SMTP purely as a bulletproof transport layer for encrypted payloads.

When someone sends you a message, ATSMS first checks if you share the same message provider. If yes, the encrypted message goes directly into the recipient’s secure inbox. If not, it falls back to SMTP delivery using MX records on your handle's domain—all without exposing sender metadata.

Messages travel as PKCS#7 MIME envelopes (application/pkcs7-mime), a format that email infrastructure already understands but can't decrypt without your keys. The beauty? Even if every ATSMS-specific server disappeared tomorrow, messages would still flow through standard email infrastructure. Unstoppable by design.

The X.509 Decision: Why "Old" Crypto Makes Sense

Critics might ask: Why X.509 certificates from the 1990s instead of encoding public keys in hex or something? There are tools and libraries for handling the complex dance of signing, encrypting, and encoding with minimal implementation errors. They're also a stepping stone toward truly encrypted email with zero metadata leaks—imagine Signal-level privacy for your Gmail. One could also envision TLS adding support for AT Protocol identities via ATSMS certificates. We will never replace email, but we can start to truly secure it.

We deliberately avoided MLS (Message Layer Security) for now. While MLS excels at large group encryption, it requires ordered packet delivery that clashes with AT Protocol's decentralized architecture. MLS in 2025 means de facto centralization. We're waiting for DCGKA (Decentralized Continuous Group Key Agreement) to mature before adding group chat support in a version of ATSMS that supports larger groups.

See It In Action: The Demo Walkthrough

View post on Bluesky

Let's walk through our live demo to see how this works in practice. We'll follow two users: @aib0b.bsky.social and @chaosmokey.skyfi.social.

Step 1: Device Setup and Key Generation

When aib0b logs into our prototype Bluesky app, something crucial happens behind the scenes. After OAuth authentication with their PDS, the app generates a unique cryptographic key pair for this specific device. The private key gets stored in the browser's local storage (remember, this is a prototype demo—production apps would use proper secure storage). Simultaneously, the public X.509 certificate uploads to aib0b's PDS, announcing to the world: "This device can receive encrypted messages for aib0b."

This demonstrates ATSMS's multi-device architecture. Each phone, laptop, or tablet generates its own certificate. Lose a device? Revoke its certificate. Get a new one? Generate a new certificate. Your conversation history remains intact because identity ties to your DID, not any single device.

Step 2: Sending an Encrypted Invitation

Now aib0b wants to message chaosmokey. When aib0b types their message and hits send, the app springs into action. First, it fetches all of chaosmokey's public certificates from chaosmokey's PDS—maybe chaosmokey has the app on their phone, tablet, and laptop, meaning three certificates.

The app signs the message with its device key, then encrypts the message with a unique symmetric encryption key, encrypting the symmetric key three times, once for each of chaosmokey's devices. This signature on the original message proves the message came from aib0b without revealing their identity in any unencrypted headers—maintaining sender anonymity against network observers.

Step 3: Smart Delivery Routing

Here's where ATSMS's architecture shines. Both users happen to use the same ATSMS provider (similar to how many people might use the same PDS). The encrypted message goes directly into chaosmokey's secure inbox—no SMTP needed.

But what if they used different providers? ATSMS seamlessly falls back to SMTP. The message would travel as an encrypted email to self@chaosmokey.skyfi.social, with MX records routing it to chaosmokey's chosen ATSMS provider. The email would look like this:

From: no-reply@atsms.at
To: self@chaosmokey.skyfi.social
Subject: ATSMS encrypted message
Content-Type: application/pkcs7-mime; smime-type=enveloped-data
Content-Transfer-Encoding: base64

MIIGHQYJKoZIhvcNAQcDoIIGDjCCBgoCAQAxggJqMIICZgIBADBOMDsxOTA3BgNV
\[...base64 encoded encrypted content...]

Notice how the sender's identity stays hidden? Only the recipient appears in cleartext. The actual sender verification happens after decryption, protecting privacy at the transport layer.

Step 4: Local Decryption and Message Management

When chaosmokey opens their app, it pulls encrypted messages from their ATSMS inbox. The app uses chaosmokey's device private key to decrypt each message locally. After decryption, it verifies aib0b's signature, confirming the message's authenticity.

Here's a crucial architectural detail: unlike traditional chat apps that rely on server-side APIs to manage conversations, ATSMS requires a local database. The client device must determine whether each decrypted message belongs to an existing conversation or represents a new chat invitation. This shifts intelligence from servers to clients—a fundamental requirement for true end-to-end encryption. In our web prototype, we use IndexDB for this, but sqlite probably makes the most sense.

Behind the Scenes: Cloudflare Workers

Our demo deployment showcases how modern edge computing makes ATSMS performant and scalable. We use Cloudflare Workers to handle two critical functions:

Email Routing Worker: Processes incoming SMTP messages for *.skyfi.social domains, extracting encrypted payloads and storing them in Cloudflare Durable Object storage based on the recipient's handle.

API Worker: Serves the ATSMS secure inbox endpoint where clients retrieve their encrypted messages. It knows nothing about message contents—just stores and serves encrypted blobs.

This architecture means ATSMS providers can't read your messages even if they wanted to. They're purely infrastructure, like internet routers passing encrypted packets.

The Roadmap: From DMs to Decentralized WhatsApp

Version 0 (Today): Encrypted DMs

Feature parity with Bluesky's current DM system, but fully end-to-end encrypted

Multi-device support with per-device keys

Decentralized message routing via DNS/SMTP fallback

Foundation for handling conversation invitations for future version of the protocol

Version 1: Small Group Chats

Client-side fanout for group messages (each client encrypts for all recipients)

Suitable for family chats, friend groups, small team discussions

Similar scale to SMS group messages or small WhatsApp groups

Version 2: Large Scale Groups

MLS integration once DCGKA standardization completes

Support for thousands of members per group

Efficient key rotation and member management

For Developers: Build on ATSMS Today

ATSMS isn't just a protocol—it's a toolkit for building secure communication into any AT Protocol application:

Open Source Libraries: Our TypeScript implementation provides everything needed to add ATSMS to your app. Generate certificates, encrypt messages, manage routing—all with a few function calls.

Standard Lexicons: Messages use at.atsms.x509 for certificate storage and well-defined message formats. Any app that speaks AT Protocol can speak ATSMS.

Provider Independence: Users choose their ATSMS inbox provider just like they choose their PDS. Your app doesn't need to run infrastructure—just integrate the client library.

Progressive Enhancement: Start with basic encrypted DMs, add group support when they’re ready. The protocol grows with your needs.

Why This Matters: The Bigger Picture

ATSMS represents more than encrypted messaging—it's a proof that decentralized systems can match centralized ones in user experience while exceeding them in maximizing user agency.

For product managers, it means building features without building prisons. Your users can leave and take their conversations with them, reducing platform lock-in liability while increasing trust.

For developers, it means focusing on user experience instead of infrastructure. Let users choose their providers while you build the features that matter.

For users, it means their conversations truly belong to them. Not to Facebook, not to Apple, not to us. Mathematical guarantees replace corporate promises.

The Future Is Now

The future of messaging isn't about choosing the right app—it's about making every app secure by default. ATSMS provides this foundation.

Your users deserve messaging that's private, portable, and permanent. ATSMS delivers all three without compromise. No trust required—it's open source, mathematically verifiable, and designed so even we can't read your messages.

The age of message monopolies is ending. The age of user-owned communication has begun.

ATSMS will be released under an open source license. Contribute, critique, or build something better. That's the point.