Protocol First, Library Second, Application Third

For years I helped build Wasabi Wallet. The work was good and the cryptography was sound. WabiSabi advanced Bitcoin privacy research in concrete ways and the wallet shipped on schedule, processing massive transaction volumes that made Bitcoin blockchain activity anonymous for everyone who used it. The chain analysis firms knew our name and they could see our outputs on every block and the math defeated them anyway. I am proud of what we built. I am also clear-eyed about what we built wrong, and what we built right turns out to be the part that is still alive today.

The error was architectural, and naming it precisely is the only honest place to begin. We built the client with care and shipped its source openly, and we wrote the WabiSabi paper and published the cryptography. The coordinator was where the discipline broke down. The wallet talked to one coordinator that our company ran, and for years that company was the only operator running one at meaningful scale. A WabiSabi paper sat openly on the internet alongside the published cryptography and the reference implementation under a permissive license, yet the operational layer remained a single team in a single jurisdiction. What we shipped was open-source software whose privacy guarantee terminated at machinery our company operated, and the machinery our company operated was where the adversary aimed.

A more honest version of the protocol-first question is whether other teams could implement against our work at reasonable cost, and there the record is mixed. BTCPay Server and Trezor both built implementations that interoperated with our coordinator, which is more than nothing. The problem was that building those implementations was harder than it should have been and maintaining them was harder still, because the specification was thin in places where the reference implementation carried implicit knowledge and the protocol surface kept moving with our internal priorities. When zkSNACKs shut down, Trezor stopped offering the feature in their software and BTCPay stopped maintaining their implementation. Independent existence had been achieved on paper. Independent sustainability had not. The implementations existed because heroic engineers at heroic companies absorbed the cost of doing something the protocol made artificially expensive. Once the social gravity of our team disappeared, the calculation flipped and the implementations stopped.

What I have described is the shape of a single point of failure inside an otherwise open system. From the inside, while you are building, the shape stays invisible because the work is hard and shipping anything is an achievement and the next sprint is always about another feature in the wallet. The wallet feels like the product because the wallet is what users open. A coordinator runs quietly in a server room and most users barely think about it. Protocol specifications exist as documents in a folder. Day to day you iterate on the application while letting the operational layer stay where it has always been, and over time the company running that layer becomes the system in everyone's mind including your own. Architectural drift happens silently and the price gets paid years later.

The price arrived. Regulators noticed that one company ran one coordinator that mediated nearly all of the meaningful CoinJoin activity on the network. A small team of people in one jurisdiction had become the operational chokepoint for a privacy feature that the broader Bitcoin community depended on. When pressure landed on that team, the company shut the coordinator down and the privacy feature stopped working through that pathway. The client kept compiling, the WabiSabi paper kept being readable, and within days other operators picked up the protocol and ran their own coordinators. The wallet still connects to one coordinator at a time, but those coordinators now advertise themselves through Nostr events, so discovery has been pulled out of the company and into a decentralized lookup layer that anyone can publish to. Wallet sync has gone the same direction: balance and block filters now come straight from the Bitcoin peer-to-peer network, with no centrally operated sync server in the path. The empirical kicker is that volumes on community coordinators today exceed what our company ever processed at the height of our operation. The system that emerged from our absence is healthier than the system we used to run. Every part of the architecture that had been protocol-shaped survived because it was protocol-shaped. Only the layer that had been operator-monopolized died with the operator, and the death cleared the way for something better than what stood in its place.

The cypherpunk premise is that freedom technology should keep working after any specific human walks away from it. That premise is easy to repeat and difficult to honor while you are shipping a product. Every shortcut that consolidates code, keys, infrastructure, or coordination authority into one team becomes a shortcut the adversary will follow back to its source. The state can route around your cryptography by routing through your operations team. The state has to find the room where your operators sit and convince those operators that continuing is more expensive than stopping. Most of the time it succeeds, because most of the time the room exists, the people are reachable, and the cost of stopping falls on users who have no seat at the table.

What I learned, expensively, is that the order in which you do the work determines whether you survive the adversary's first serious move, and the cost at which other teams can implement determines whether the survival is real. Build the application first and the protocol decays into documentation that other teams glance at but never implement, while your library decays into a wrapper around your own internals. If you ship a protocol whose specification is thin and whose true behavior lives in the reference implementation, the third-party implementations will exist and then die, because no one will sustain the heroic effort of reading your source code and guessing at your conventions once your team stops being there to ask. Only when the protocol is documented thoroughly enough that another team can implement against the specification alone does the contract become cheap enough for other teams to build against it and keep building against it. The moment a second implementation exists at reasonable cost, you have a system the adversary can damage only by attacking every implementer at once, which is an attack budget most adversaries cannot sustain. Libraries belong second because libraries are how you make the protocol cheap for other developers to adopt, abstracting the hard parts of cryptography and networking and state management into interfaces application developers can use without becoming specialists in any of those domains. Applications belong third because applications are the surfaces that touch users, and surfaces should be plural. Many applications competing on user experience over a common protocol is what a healthy system looks like. One application acting as the on-ramp to a privately operated coordinator is what a target looks like.

This discipline inverts the order that feels natural while you are working. The natural order builds the application first because the application is what proves the idea while attracting the early users whose feedback shapes the next iteration. Protocol-first work writes the specification before there are users and refuses to ship features in the application that the specification cannot describe, accepting that few people will read the specification at the start. Libraries follow because the moment the specification is real, you owe other implementers the tools to build against it. The application arrives third because the application is the easiest part once the layers underneath are honest. Inverting the natural order is uncomfortable. The reward is that the system survives you.

Marmot is the application of this discipline to private group messaging. The Marmot Protocol specifies how to combine MLS, the IETF-standardized cryptographic protocol for secure groups, with Nostr as the transport. Six Marmot Implementation Proposals, MIP-00 through MIP-05, each define one layer of the system: how identity works, how groups form, how new members join, how messages travel, how media gets encrypted, and how push notifications reach mobile devices while keeping metadata away from Apple and Google. Four of those proposals are mandatory for any compatible implementation. Two are optional extensions. Each specification is public and versioned, with a public threat model alongside it. All of them were written before there were any users.

A library layer exists alongside the protocol, and after a relatively short development period the inventory is already substantial. The Marmot Development Kit is the Rust reference implementation, with native bindings published for Kotlin, Python, Ruby, Swift, and Web/WASM, so application developers can call into the protocol from whatever language and platform they target. Beyond the bindings, four genuinely independent implementations of the protocol have appeared: marmot-ts in TypeScript, marmot-cs in C#, Marmot support added to Quartz, the existing Kotlin Multiplatform Nostr library used by the Amethyst Android client, and the original MDK in Rust. Storage adapters for Sled and Redb sit alongside an LMDB option, giving implementers a choice in how they persist MLS state. Specialized tools have shown up around the edges, including a notifications server, a diagnostic tool for Nostr identities, a test harness for MLS proposal and commit scenarios, and several CLIs and bot frameworks built by people who have no formal relationship to the protocol authors. The list keeps growing because the specification is cheap enough to build against that contributors keep building.

White Noise occupies the application layer. White Noise is a chat client that uses the Marmot protocol through the MDK library to provide secure private messaging over Nostr. A Rust core crate powers a Flutter mobile app, and the Rust crate is itself frontend-agnostic, so command-line interfaces, desktop clients, and other applications can be built against the same core. What I care about is the Marmot protocol. White Noise is the application I am putting work into because someone has to build a reference client and I am positioned to help, and I would be perfectly content with a different Marmot client becoming the one people use most, as long as the protocol is what they end up using. The application matters to me only as a means by which the protocol reaches more people, and any other application that does that job is a friend doing work I want done. Around a dozen independent applications have already been built on Marmot by contributors with no formal relationship to the protocol authors, including a Flutter mobile app, a terminal UI client, a desktop helper that turns the protocol into a control surface for local AI agents, a peer-to-peer multiplayer game, a private family video sharing app, and several encrypted messengers built by independent teams. Amethyst, the major Android Nostr client with hundreds of thousands of installs, added Marmot support directly to Quartz, the existing Kotlin Multiplatform Nostr library that powers it, and ships interoperably with everything else on the network. Scramble built an equivalent Marmot implementation in C# on .NET from scratch. These two cases are the strongest possible evidence that the discipline is working as intended: independent teams reading the specification and shipping their own implementations that stay interoperable with the rest of the system without coordination from the protocol authors. The list spans hobby projects, agent infrastructure, niche specialized tools, and mainstream Nostr clients that already serve large user populations.

If White Noise stopped shipping tomorrow, the Marmot protocol would continue. Anyone could pick up the specifications and build a compatible client. MLS is a published cryptographic standard maintained by the IETF. Nostr transport is operated by hundreds of independent relays run by people I have never met. Sound cryptography sits in the IETF standards and decentralized transport runs across hundreds of relays, with open specifications anyone can read, and the messaging system stays resilient under pressure on any individual team or jurisdiction that decides private group messaging is too dangerous to permit. Work I do on White Noise is operational contribution to a system that runs without me, and that kind of work is the only kind in freedom technology that compounds over time.

Nostr itself is the standing proof that this strategy works. Its protocol is a small set of Nostr Implementation Possibilities, the original specification published by fiatjaf and extended by contributors he has never met in person. The protocol belongs to whoever implements it. Anyone can run a relay, anyone can build a client, and the network is the union of whatever those independent parties happen to have running at any given moment. Independent teams have built clients in different languages targeting different platforms with different design philosophies, and they all interoperate because the specifications are public, the events are signed, and the relays are dumb enough to be replaceable. When a relay operator gets pressured, the network routes around them. When a client team gives up or sells out or pivots to advertising, users move to another client and bring their identity and their social graph with them because both of those live in the protocol layer where they cannot be taken away. Protocol-first design is what makes Nostr resistant to the failure modes that killed every previous attempt at decentralized social media. Adversaries who break something break only locally. The network as a whole stays up because the network as a whole has no single point an attacker can break.

The contrast with the systems Nostr competes against is sharp and instructive. Federated social protocols whose identity model depends on the server you signed up with create a chokepoint at every server operator. Encrypted messaging platforms with one company running the infrastructure create a chokepoint at that company, and the chokepoint doubles when the same company is also the only place to get the application. Privacy-preserving wallets with one coordinator create a chokepoint at the coordinator. The pattern is consistent and the lesson is consistent. Real protocols paired with plural implementations and distributed operators produce a system that absorbs the loss of any participant while keeping the property that mattered. Drop any of those three conditions and the system acquires a kill switch, which an adversary will sooner or later reach for.

For anyone building freedom technology, the practical discipline reduces to a small set of habits that are easier to state than to follow. Write the specification first, even when it feels premature. Publish the threat model alongside the protocol so other implementers can reason about what you are claiming. Resist the temptation to ship features in your application that the specification cannot yet describe, because every such feature is a coupling that pulls users toward your application and away from the protocol. Make it easy for other teams to build against your work by writing libraries with stable interfaces alongside clear documentation that honestly acknowledges the parts still in motion. Treat your own application as one implementation among many, even when it is the only one that exists yet, because the day a second one ships is the day your work becomes durable. Invite people in. Answer their questions. Help them build the libraries you wish existed. The goal is to make the protocol cheaper to adopt than to ignore.

I write this with full awareness that Marmot has yet to prove anything. The protocol and the implementations are both still young, and the test that matters is whether the system survives the kind of pressure that broke the previous attempt. Whether we will pass that test remains open. I do know what the architecture has to look like for the test to be passable, and I know what the architecture looks like when the test is unpassable, because I built the unpassable version myself and watched it fail under intense, sustained regulatory pressure that found exactly the chokepoint our architecture had handed it. The lesson cost me years. I would rather it cost no one else the same.

The work I want to see is more protocols and more libraries and many more applications. The work I want to see less of is single-vendor stacks that look decentralized on the marketing page and have a phone number in the back room for a prosecutor to call. Freedom technology has always been a contest between architectures and adversaries, and the architectures that survive are the ones an adversary cannot find a person to call about. The order of operations is protocol first, library second, application third. That order produces systems that outlive their founders. The reverse order produces systems whose founders outlive the systems. I have written enough of the second kind to recommend that we all try to write more of the first.