AT-SMS: Building Decentralized End-to-End Encrypted Messaging on AT Protocol
Today, I'm super excited to introduce AT Secure Messaging Service (AT-SMS): 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. AT-SMS extends this breakthrough to private messaging.
Instead of building yet another centralized service with promises to "open up someday," AT-SMS 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 AT-SMS Works: A Technical Deep Dive
AT-SMS 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 AT-SMS 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, AT-SMS 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 AT-SMS 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, AT-SMS 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 AT-SMS-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 AT-SMS 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 MLS support in a version of AT-SMS that supports large group chats.
See It In Action: The Demo Walkthrough
I'd say look what I've cooked up, but my man with no the yellow hat doesn't let me play with the stove.🐒 So don't tell him about this, but I built a prototype of E2EE encrypted chat on a fork of the Bluesky App.
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 AT-SMS'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 AT-SMS's architecture shines. Both users happen to use the same AT-SMS 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? AT-SMS 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 AT-SMS provider. The email would look like this:
From: no-reply@atsms.at
To: self@chaosmokey.skyfi.social
Subject: AT-SMS 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 AT-SMS 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, AT-SMS 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 AT-SMS performant and scalable. We use Cloudflare Workers to handle two critical functions:
Email Routing Worker: Processes incoming SMTP messages for
*.skyfi.socialdomains, extracting encrypted payloads and storing them in Cloudflare Durable Object storage based on the recipient's handle.API Worker: Serves the AT-SMS secure inbox endpoint where clients retrieve their encrypted messages. It knows nothing about message contents—just stores and serves encrypted blobs.
This architecture means AT-SMS 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 AT-SMS Today
AT-SMS 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 AT-SMS 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 AT-SMS.
Provider Independence: Users choose their AT-SMS 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
AT-SMS 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. AT-SMS provides this foundation.
Your users deserve messaging that's private, portable, and permanent. AT-SMS 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.
AT-SMS will be released under an open source license. Contribute, critique, or build something better. That's the point.