A Vision for End-to-End Encrypted Messaging on ATproto
End-to-end encrypted (E2EE) messaging built on ATproto could become the open, decentralized alternative to WhatsApp—free from lock-in, surveillance, and privacy compromises. To achieve this, we must design the messaging protocol with precision, upholding ATproto’s core principles while ensuring communications remain private and secure.
Signal sets the benchmark for private E2EE communication. In a recent X post, Meredith Whittaker, Signal’s CEO, stated:
Signal is the gold standard in private comms. We're open source, nonprofit, and we develop and apply e2ee and privacy preserving tech across our system to protect metadata and message contents.
Neither consumer nor business WhatsApp protects intimate metadata— like contact list, who's messaging whom, when, profile photo, etc. And, when compelled, like all companies that collect the data to begin with, they turn this important, revealing data over.
Don't misunderstand—we love that WhatsApp uses our tech to raise the privacy bar of their app. Part of Signal's mission is to set, and encourage the tech ecosystem to meet, this high privacy bar.
Signal’s mission includes raising the privacy bar for the entire tech ecosystem—a bar that ATproto messaging should aim to meet. Unlike WhatsApp, which exposes metadata despite using Signal’s encryption tech, ATproto should protect both message contents and metadata while staying true to its decentralized roots.
Beyond matching Signal’s privacy standards, ATproto messaging must embody its foundational principles:
- Multiple interoperable providers for every component
- Easy provider switching for users.
- User agency over their experience and content.
- Simple usability, shielding users from the complexity of decentralization
These goals will manifest differently in an E2EE messaging protocol than in a public microblogging app like Bluesky. The ultimate aim is to create a protocol akin to SMTP for email—where anyone can build interoperable clients and infrastructure—while maintaining Signal-level privacy. Below, we explore how ATproto’s pillars apply to designing private messaging.
A stake in the ground
Before exploring the design of ATproto’s private messaging, let’s set a foundation: E2EE messaging requires the sending device to manage message encryption keys to safeguard privacy—a straightforward task for mobile apps, though more challenging for web clients. This requirement is critical, as it fundamentally influences how we implement E2EE on ATproto while upholding its decentralized ethos and social contract.
This approach builds on the ATproto decentralized account (did:plc) and PDS. For ATproto private messaging, the DID and PDS hold the user’s identity keys and establish identity in the encrypted communications by signing these device encryption keys using the identity keypairs.
Decentralization
Bluesky and other ATproto apps operate on a federated framework, distributing control across multiple servers rather than a single authority with the user at the center of this choice of servers. Users can host data on personal or third-party servers, reducing reliance on one entity and enabling cross-platform interoperability. This prevents any single organization from dominating the network, much like email across providers.
For E2EE messaging, this approach poses unique challenges:
- Metadata privacy: How do we route messages without network traffic revealing who’s talking to whom? The goal is to surpass WhatsApp, not mimic it.
- Group messaging: The Messaging Layer Security (MLS) standard, widely used for encrypted group chats, typically centralizes message ordering. How can we adapt MLS—or an alternative—for ATproto’s decentralized network?
Message routing
A naive approach to message routing is to leverage the user’s Personal Data Server (PDS) to store messages and manage signed encryption keys. However, this poses a challenge: if most users rely on the same provider for their PDS, metadata privacy weakens, resembling centralized systems. Instead, dedicated messaging servers that handle messages from many different users should be used. The messages themselves carry no identifiers that can map back to specific users. Instead the users use an encrypted protocol to agree on random identifiers to identify conversations.
Decentralizing MLS
MLS requires group members to agree on message order, often handled by a central server in current deployments. For ATproto, we need a solution that avoids centralization while preserving privacy of group membership from outsiders. This echoes challenges in decentralizing identifiers like did:plc, but with added privacy stakes.
There are two projects that use MLS without relying on centralized servers to do message ordering:
These examples suggest MLS can adapt to ATproto’s needs, leveraging its growing ecosystem of libraries and scrutiny from the security community. Alternatively, we could abandon MLS and craft a custom protocol tailored to ATproto’s priorities—decentralization and privacy from the ground up. However, sticking with MLS offers practical advantages: broader adoption, tested tools, and ongoing refinement.
Freedom to Exit
Bluesky emphasizes portability, ensuring users can leave without losing their social graph or data. For ATproto messaging, this means users can switch apps seamlessly. All new conversations should start with ATproto’s decentralized account IDs, not app-specific identifiers.
But, unlike public social graphs, messaging involves private contacts and ongoing private conversations. Traditionally, mobile devices manage contacts, but recent iOS changes restrict app access to this data. Should we rely on device-native contacts, or integrate them into the private Personal Data Server (PDS) being developed?
The core of this freedom to exit lies in ensuring that users can send direct messages (DMs) to any other ATproto user, no matter which messaging app they choose, because all apps rely on the same ATproto private messaging protocol. This interoperability eliminates the silos that trap users in traditional platforms, empowering them to switch apps without losing access to their conversations or contacts across the network.
User Autonomy and Choice
Users should control their messaging experience—deciding who can message them, managing inbound chat invites, and customizing interactions. While apps will handle these features, the underlying protocol must support them.
E2EE conversations will likely use ATproto accounts as endpoints, but users should dictate how much identity data (beyond the account ID) is shared. This agency aligns with ATproto’s ethos of empowering individuals over corporate gatekeepers.
Community Governance
As an open-source project, Bluesky’s code is accessible, encouraging developers and users to contribute to its evolution. The ethos here is to build a transparent, collaborative infrastructure that evolves with societal needs, rather than being dictated by a single company’s interests. The same is true for ATproto messaging.
One specific area that ATproto governance will play a tangible goal will be in the richness of the messaging protocol itself. Things like emoji responses, replies and threaded conversations are all aspects of the protocol that the community needs to drive. Is this an appropriate use of lexicons? Apps building on the ATproto messaging should also be able to introduce new lexicon specific to their app.
Let’s Build It
This post is a starting point—a call to align on goals and define the components needed for E2EE messaging on ATproto. The vision is clear: a protocol that rivals SMTP in openness, matches Signal in privacy, and embodies ATproto’s decentralized promise. Join us in making it real.
