Something clicked for me while reading Chris Boscolo's recent introduction to AT-SMS. Maybe we've been thinking about decentralized messaging wrong. Instead of trying to replace email, what if we just... used email? But not in the way you might think.

Chris's proposal sparked some ideas that I think could expand on his foundation. While he's focused on using DNS MX records for routing, I see an opportunity to decouple SMTP services from domain ownership entirely by adding them directly to DID documents. Combined with an XRPC method for signing and encrypting content at the PDS level—something that aligns naturally with the attestation lexicon I've been working on—we could create something even more flexible and powerful.

The beauty of what emerges from this thinking isn't just about encrypted messaging. It's about something more fundamental: proving who you are in a way that's both cryptographically secure and refreshingly simple. When you send an email from one ATProtocol handle to another, you're essentially creating a JWT-like proof of identity, but one that travels over infrastructure that's been battle-tested for five decades.

The Identity-First Approach

Here's what makes this approach so compelling: when you add an SMTP service endpoint directly to your DID document, you're making a claim about where you can receive messages. This goes beyond Chris's DNS-based approach—you don't need to control a domain or manage MX records. Your DID document becomes the single source of truth for how to reach you, whether that's through a traditional email server, a specialized messaging service, or something else entirely.

This isn't just a technical detail—it's a consent mechanism. Only someone who controls the DID can update that document, which means if an SMTP endpoint is listed there, the owner has explicitly authorized it. No centralized authority needed, no complex key distribution problem to solve. The discovery process becomes straightforward: resolve the DID, find the SMTP service, send the message. No DNS lookups required unless the service itself chooses to use domain-based routing.

Think about it this way: in traditional email, anyone can claim to be sending from any address. SPF, DKIM, and DMARC are all band-aids trying to fix this fundamental flaw. But with ATProtocol handles backed by DIDs, the sender can cryptographically sign their message, and the recipient knows with mathematical certainty who sent it. It's like having a notarized letter delivered by regular postal service—the transport doesn't need to be secure because the content itself carries proof of authenticity.

The PDS as a Cryptographic Service

Where this gets really interesting is when we consider the PDS not just as a data store, but as a cryptographic service provider. Imagine an XRPC method that any client can call to sign or encrypt content on behalf of the user. This is where the attestation framework I've been developing fits naturally into the architecture—and from my conversations with Chris, there's definitely a place for it in this system.

The attestation lexicon provides a standardized way for a PDS to sign statements on behalf of an identity. Applied to messaging, this means your PDS could sign outbound messages, proving they came from you without the client needing direct access to private keys. For encryption, the PDS could handle the key management complexity while still ensuring that only authorized devices can decrypt the actual message content.

This separation of concerns is powerful. Clients become simpler—they just need to call XRPC methods. The PDS handles the cryptographic heavy lifting. And users maintain control through their DID document, which specifies which PDS they trust with these operations.

The elegance extends to how devices get authorized. Chris's approach of storing X509 certificates in the PDS solves a thorny problem: how do you prove a device is authorized to receive messages for an identity without creating yet another centralized registry? If the certificate exists in your PDS, you put it there. You control it. You can revoke it. The authorization model becomes dead simple: presence equals consent.

Group Messaging Without the Coordination Dance

One of the most interesting implications of this architecture is how it handles group messaging. Traditional encrypted group chat systems tie themselves in knots trying to coordinate key distribution and rotation. But when each identity has its own cryptographic material accessible through their PDS, group messaging becomes almost trivial from a protocol perspective. You're not managing a shared group key; you're just sending individual encrypted copies to each recipient.

The attestation framework could make this even more efficient. Instead of the client encrypting for each recipient, it could make a single XRPC call to the PDS with the message and recipient list. The PDS handles the fan-out, signing the message once and encrypting it for each recipient's published certificates. This moves the computational burden to the server side where it can be optimized and parallelized.

This might seem inefficient at first glance—why encrypt the same message multiple times? But it eliminates entire categories of complexity. No key agreement protocols. No complex state machines for handling members joining and leaving. No coordination servers that become single points of failure. Each message is just a collection of individually encrypted payloads, each one provably from the sender and readable only by its intended recipient.

SMTP as a Universal Fallback

What really strikes me about using SMTP as the transport layer is its universality. Every domain can receive email. Every hosting provider supports it. Every corporate firewall allows it. By piggybacking on SMTP, AT-SMS gets instant global reach without having to bootstrap a new network.

But by putting SMTP services in the DID document rather than relying solely on DNS MX records, we gain even more flexibility. Your handle could be @alice.wonderland.social, but your SMTP endpoint could be smtp.somewhereelse.com. You're not tied to your handle's domain for message routing. This decoupling means you could change handle providers without changing your messaging infrastructure, or vice versa.

The implementation flexibility this provides is remarkable. Your SMTP service listed in your DID document could be a full email server supporting IMAP or POP. It could be a simple forwarder that routes to your existing email. It could be a specialized service that only handles ATProtocol messages. It could even be a bridge to other messaging protocols. The protocol doesn't care—it just needs somewhere to deliver encrypted blobs.

This also means the system is inherently resilient. Even if every specialized ATProtocol messaging server disappeared tomorrow, the messages would still flow through regular email infrastructure. They'd be unreadable to anyone except the intended recipients, but they'd get delivered. That's the kind of architectural resilience that only comes from building on proven foundations.

Building on Boring Technology

There's a principle in software engineering: build on boring technology. DNS is boring. SMTP is boring. X509 certificates are boring. XRPC is becoming boring (in the best way). And that's precisely why this approach is so powerful. These aren't exciting new protocols that might have undiscovered flaws. They're technologies that have been hammered on for decades, with well-understood properties and failure modes.

The addition of SMTP services to DID documents and PDS-level cryptographic operations through XRPC doesn't add complexity—it removes it. Instead of managing DNS records and MX entries, you update your DID document. Instead of handling keys in every client, you make XRPC calls. The boring technology stack gets even more boring, which is exactly what you want.

Chris's choice to avoid backward compatibility with legacy email encryption is particularly smart. S/MIME and PGP carry decades of baggage, from key discovery problems to usability nightmares. By using SMTP purely as transport for already-encrypted ATProtocol messages, we get the infrastructure benefits without the complexity debt.

What This Means for the Future

What excites me most about this approach is how it could transform our relationship with messaging. Today, every app is an island. Your WhatsApp messages, your Discord conversations, your Slack threads—they're all trapped in their respective silos. But if messaging becomes a protocol-level capability tied to your portable identity, with cryptographic operations handled by your PDS and routing information in your DID document, suddenly every app can be a messaging app.

Imagine opening your favorite ATProtocol client and having all your messages there, regardless of which app the sender used. Imagine switching clients without losing a single conversation. Imagine knowing that your messages are truly yours, not held hostage by whatever company happens to run the server.

The attestation framework adds another layer to this vision. Your PDS becomes not just a data store but a cryptographic agent acting on your behalf. It can sign statements, encrypt messages, and verify claims—all through standardized XRPC methods that any client can use. This isn't just about messaging; it's about building a foundation for all kinds of cryptographic operations in a decentralized identity system.

The Path Forward

Chris's AT-SMS prototype, running on Cloudflare Workers, proves this isn't just theoretical. The foundations are solid, and the additions I'm proposing—DID document SMTP services and PDS-level cryptographic operations—build naturally on what he's created. Version 0 achieves feature parity with existing DM systems while adding end-to-end encryption. The path forward is clear.

For developers, the implications are profound. Adding secure messaging to your ATProtocol app becomes as simple as resolving a DID to find the SMTP endpoint and calling XRPC methods for cryptographic operations. You don't need to run messaging infrastructure. You don't need to solve key distribution. You just need to speak the protocol.

The convergence of Chris's practical SMTP transport approach with the attestation and cryptographic frameworks being developed for ATProtocol creates something more than the sum of its parts. It's not just secure messaging—it's a model for how decentralized identity systems can provide real, usable services without sacrificing user control.

The decision to open source everything from day one is crucial. This isn't a company trying to build a moat; it's a community trying to build infrastructure. The code is there to examine, critique, and improve. The specifications are open to implement. The architecture is decentralized by design.

We're watching the early stages of something that could fundamentally reshape how we think about digital communication. Not by replacing email, but by making it the secure, verifiable transport layer it always should have been. Not by building new walled gardens, but by tearing down the walls entirely.

The future of messaging isn't about picking the right app. It's about making every app speak the same secure, open protocol. And building it on top of SMTP—boring, reliable, universal SMTP—combined with the identity and cryptographic primitives of ATProtocol, might just be the key to making it work.