The Problem They Said Could Not Be Solved

Every serious attempt to build encrypted group messaging for more than two people has collided with the same wall: the problem demands properties that contradict each other. Members must agree on shared encryption keys without a coordinator. The system must provide forward secrecy, meaning a compromise today cannot expose yesterday's messages, while also providing post-compromise security, meaning a recovery tomorrow restores full protection. Members join and leave at unpredictable times, and every change requires updating cryptographic state across all remaining participants. Messages must arrive in consistent order across a network where latency varies and nodes disappear without warning. All of this must happen without any single server that a government could compel or an adversary could compromise.

The people who understand this problem best have been the most emphatic about its difficulty.

"I No Longer Believe That It Is Possible"

Moxie Marlinspike built Signal, the most trusted encrypted messenger in the world, on a deliberately centralized architecture. In May 2016, he published "Reflections: The ecosystem is moving" on the Signal blog, explaining why:

"Nothing about any of the protocols we've developed requires centralization; it's entirely possible to build a federated Signal Protocol-based messenger, but I no longer believe that it is possible to build a competitive federated messenger at all."

His reasoning was structural. Federated protocols cannot evolve because every participant must agree on changes, and that agreement never comes. He pointed to the wreckage of every federated standard that came before:

"We got to the first production version of IP, and have been trying for the past 20 years to switch to a second production version of IP with limited success. We got to HTTP version 1.1 in 1997, and have been stuck there until now. Likewise, SMTP, IRC, DNS, XMPP, are all similarly frozen in time circa the late 1990s."

XMPP, the protocol most people point to as proof that federated messaging can work, became his primary exhibit for why it cannot. Signal had originally used XMPP before abandoning it:

"Like any federated protocol, extensions don't mean much unless everyone applies them, and that's an almost impossible task in a truly federated landscape. What we have instead is a complicated morass of XEPs that aren't consistently applied anywhere."

The metadata problem compounded the architectural one. Even if you encrypt every message, a decentralized network leaks information about who is talking to whom and when. Moxie argued that protecting metadata would require innovation that centralized systems could deliver and federated ones could not: "Those changes are only likely to be possible in centralized environments with more control."

Six years later, his position had hardened. In his January 2022 essay "My first impressions of web3," he extended the argument to all decentralized systems:

"People don't want to run their own servers, and never will. Even nerds do not want to run their own servers at this point."

And the core architectural claim: "If something is truly decentralized, it becomes very difficult to change, and often remains stuck in time. That is a problem for technology, because the rest of the ecosystem is moving very quickly, and if you don't keep up you will fail."

For group messaging specifically, Signal's own implementation confirmed the difficulty. In a 2014 Signal blog post on private group messaging, Moxie explained why the academic multi-party protocol (mpOTR) was impractical for real-world use: "In an asynchronous environment, clients need to be able to immediately transmit their message without depending on any interactivity from any of the recipients, so even a single round trip is too much." Signal's actual solution for groups was to give up on elegance entirely and send each message as a separate pairwise encrypted copy to every group member individually, burning bandwidth for simplicity.

The Cryptographers Agreed

Matthew Green, the Johns Hopkins cryptographer whose blog is the field's most-read source of security analysis, confirmed in 2018 that even centralized group messaging remained "still kind of a hack." Analyzing vulnerabilities found in both Signal and WhatsApp by researchers at Ruhr University Bochum, Green wrote: "The greatest lesson of all time is that real cryptosystems are always broken this way, and almost never through the fancy cryptographic attacks we love to write about."

The specific weakness Green identified was group key distribution. The Signal protocol works well for two people. For groups, "the standard Signal protocol doesn't work quite as well for group messaging, primarily because it's not optimized for broadcasting messages to many users." Every approach to group encryption involves tradeoffs that the two-party case avoids entirely.

Telegram provides the starkest illustration: a company with hundreds of millions of users and full centralized control over its infrastructure has never managed to ship encrypted group messaging at all. As Green documented in August 2024: "The feature is explicitly not turned on for the vast majority of conversations, and is only available for one-on-one conversations, and never for group chats with more than two people in them." If a centralized company with unlimited resources cannot do it, the decentralized case seems hopeless.

The IETF Tried and Hit the Same Wall

The Messaging Layer Security protocol, published as RFC 9420 in July 2023, represents the most rigorous academic attempt to solve encrypted group messaging. Authored by researchers from Cisco, Mozilla, Meta, Inria, and the University of Oxford, MLS introduces a ratchet tree structure that reduces the cost of group key updates from O(N^2) in the sender-keys approach to O(log N), making groups of thousands cryptographically feasible for the first time.

MLS is a real achievement, but it explicitly requires two centralized services to function. From the RFC itself: "An Authentication Service (AS) that enables group members to authenticate the credentials presented by other group members" and "A Delivery Service (DS) that routes MLS messages among the participants in the protocol."

The Delivery Service requirement exists because MLS needs someone to order commits. Each state transition in an MLS group moves the group to a new epoch, and all members must agree on which commit ends one epoch and begins the next. Without a sequencer, competing commits create forks that fracture the group's cryptographic state. The RFC acknowledges this directly: "Each Commit message is premised on a given starting state. Applications MUST have an established way to resolve conflicting Commit messages for the same epoch."

The MLS architecture document does acknowledge that a "peer-to-peer network could instantiate a decentralized DS by transmitting MLS messages over that network," but immediately qualifies: "clients will need to implement logic that assures the delivery properties required of the DS." Nobody had built that logic. The hard part of decentralized group messaging was exactly the part MLS left as an exercise for the reader.

Every Attempt Failed

Matrix, the most well-funded attempt at decentralized encrypted group messaging, proved the skeptics right in the worst possible way. In 2022, researchers from Royal Holloway, University of London, and the University of Sheffield published a devastating analysis finding that Matrix's encryption "provided neither authentication nor confidentiality against homeservers that actively attack the protocol." The system that millions of users trusted for secure communication was broken at the foundation.

The attacks were not exotic. A malicious homeserver could add users under its control to encrypted rooms because room management messages were not authenticated, even for encrypted rooms. A chain of attacks allowed the homeserver to extract all inbound encryption sessions from a target user. The researchers identified a systemic failure: "the specification and its implementations seem to have grown organically with new sub-protocols adding new functionalities and thus inadvertently subverting the security guarantees of the core protocol."

XMPP fared no better. OMEMO, the encryption extension that was supposed to bring forward secrecy to federated XMPP messaging, operates on pairwise Double Ratchet sessions between every device pair. For a group of N members each with D devices, the protocol requires N times D separate encryption operations per message. This is the approach that Trail of Bits, in their 2019 analysis of MLS, classified as fundamentally unscalable: the same architecture that iMessage uses and that breaks down above a few hundred participants.

The pattern across these failures is consistent. Each project solved part of the problem while leaving critical gaps that compounded into system-wide vulnerabilities. Matrix got the federation model working but failed on cryptographic guarantees. OMEMO got the encryption right for two parties but could not extend it to groups without quadratic overhead. Signal got both encryption and groups working but required centralized infrastructure that created a single point of failure and a single point of compulsion. Every attempt confirmed what the skeptics had been saying: the full problem, all properties simultaneously, appeared to be beyond reach.

What Changed

Two things changed between Moxie's 2016 essay and today. The first was MLS itself. Despite its centralization requirement, MLS solved the cryptographic layer of group key agreement with mathematical rigor that no previous protocol had achieved. Its ratchet tree construction makes group encryption scale logarithmically while providing both forward secrecy and post-compromise security through epoch transitions, and a proposal-and-commit mechanism handles asynchronous membership changes when participants are offline. The cryptography works. What remained unsolved was the transport and identity layer underneath it.

Nostr provided the missing piece. A global network of thousands of independently operated relays, communicating over WebSocket connections, with identity rooted in secp256k1 keypairs that require no registration and no phone number. Nostr was not designed for encrypted messaging but for censorship-resistant social communication. Yet the properties it provides turn out to be exactly what MLS needs and does not specify: user discovery, message delivery, identity authentication, all without any central authority.

The Marmot protocol, formalized through a series of Marmot Implementation Proposals (MIPs), connects these two systems. Marmot uses MLS for everything MLS does well: group key agreement, ratchet tree management, epoch transitions, forward secrecy, post-compromise security. It uses Nostr for everything MLS left unspecified: identity through keypairs, discovery through KeyPackage events published to relays, message delivery through the relay network, and metadata protection through ephemeral keypairs and NIP-59 gift wrapping.

The specification is precise where it needs to be. MIP-00 defines how Nostr identity maps to MLS credentials, with signing keys deliberately separated from Nostr identity keys so that compromising one does not compromise the other. Group construction follows in MIP-01, which introduces a custom MLS extension carrying group metadata and admin permissions alongside relay preferences. Welcome events for group invitations come through MIP-02, wrapped in NIP-59 gift wrap for unlinkability. And MIP-03 defines the encrypted group message format, using ChaCha20-Poly1305 with keys derived from MLS epoch secrets, and critically, generating a fresh ephemeral secp256k1 keypair for every single message so that no observer can link messages to their sender.

The commit ordering problem that MLS left to the application layer gets a deterministic solution: competing commits resolve by timestamp priority with lexicographic ID as the tiebreaker. Members retain prior group state temporarily to recover from forks without sacrificing forward secrecy. It is not a perfect solution, and the specification acknowledges the tradeoffs explicitly, but it is a working solution that does not require a central sequencer.

The Protocol Matters More Than the App

White Noise is the first application implementing Marmot, and it ships today with end-to-end encrypted direct and group messaging, no phone number or email required, running on the decentralized Nostr relay network. The Rust core library (whitenoise-rs) provides the cryptographic engine while Flutter clients run on iOS and Android, funded by OpenSats, the Human Rights Foundation, and the Jack Dorsey-backed "And Other Stuff" collective.

But the application is not the point. Marmot is a protocol specification with interoperability built into its architecture, and that distinction matters more than any single client. Four mandatory MIPs define event kinds (443 for KeyPackages, 444 for Welcomes, 445 for group messages) with encryption schemes and message flows specified precisely enough that any independently developed client can exchange encrypted messages with any other. SDKs already ship in Rust, TypeScript, Kotlin, Swift, Python, and Ruby, covering every platform a messaging developer would need.

Interoperability at the protocol layer is the architectural choice that separates Marmot from every previous attempt. Signal's encryption is excellent, but Signal is a walled garden: one app, one server infrastructure, one organization that must continue to exist for the system to function. Matrix attempted federation but grew its specification organically, accumulating sub-protocols that undermined each other's security guarantees. XMPP federated successfully but froze in the late 1990s, exactly as Moxie predicted, because getting a federated network to adopt new extensions proved impossible in practice.

Marmot avoids the federation trap by building on a network that already exists and already evolves. Nostr relays do not need to agree on protocol changes because the Marmot specification lives in the client layer, not the relay layer. Relays store and forward events without understanding their contents. A Marmot client can implement new MIP versions without requiring any relay operator to update anything. The protocol evolves at the speed of client development, which is the speed Moxie always argued was necessary, while running on infrastructure that no single entity controls.

Separating the cryptographic protocol from the transport network also means that Marmot inherits MLS's security properties by reference. Academic cryptographers have formally analyzed MLS through years of IETF review, and the resulting RFC carries the rigor that process demands. Marmot does not need to reinvent group key agreement or prove novel cryptographic constructions secure. It needs to correctly implement MLS and correctly map its operations onto Nostr's event model, a substantially smaller and more verifiable surface area than designing a complete encrypted group messaging system from scratch.

The Hardest Problem in Applied Cryptography

The academic literature on Continuous Group Key Agreement, the formal primitive underlying MLS, continues to evolve. Researchers have found and fixed attacks on TreeKEM, the core ratchet tree construction, including forward secrecy gaps identified by Alwen, Coretti, Dodis, and Tselekounis in 2019 and insider attacks documented by Alwen, Jost, and Mularczyk in 2020. These fixes were incorporated into the MLS standard before publication. The research process works, and Marmot benefits from it directly because it builds on MLS's foundations.

The specification has passed a formal security audit at the protocol layer, and audits of the MDK and whitenoise-rs implementations are in progress. The commit ordering mechanism trades theoretical optimality for practical simplicity, and adversarial conditions could produce edge cases that the current conflict resolution rules do not handle gracefully. These are real limitations, and acknowledging them is part of what makes the specification credible: a project that claims to have solved every aspect of a problem this hard would not be worth taking seriously.

What makes Marmot worth watching is the architectural bet. The protocol splits the problem along the exact seam that previous attempts missed. MLS provides the cryptographic engine, formally verified and standardized. Nostr provides the decentralized transport, already running at scale across thousands of relays with millions of users. Marmot defines the binding layer between them, thin enough for independent audit and precise enough that any developer can implement it without asking anyone's permission.

The people who said decentralized encrypted group messaging could not be done were not wrong about the difficulty. They were wrong about the conclusion. The problem was never impossible. It was waiting for the right combination of a proven cryptographic standard and a decentralized network with the right properties to appear at the same time. MLS and Nostr are that combination, and the Marmot protocol is the specification that connects them.