Building an Armada: Our Voyage to Encrypted Communities on Nostr

If you've followed my work on Nostr for any length of time, you know I don't usually lead with the hard parts. I'm the guy on stage telling you why this protocol is going to change everything. I believe that. But I want to tell a different kind of story here, the one about how many times we hit a wall trying to do something that sounds simple: let people send each other a private message.

Turns out "private message" is one of the hardest things to build on an open protocol. And we've been chasing it, in one form or another, for years. Here's the voyage we actually sailed to get to something I'm proud of. It was not a straight line.

NIP-04, and the lie of the little lock icon

In the beginning there was NIP-04, the original encrypted direct message. It worked, sort of, and for a long time it was all we had. You could send someone a DM and the content was encrypted. Job done, right?

Not even close. NIP-04 encrypted what you said but broadcast everything about the fact that you said it. The metadata was wide open: anyone watching the relays could see that this pubkey messaged that pubkey, at this time, this often. For most social apps that's a bad look. For the people Soapbox builds for, activists, dissidents, people whose threat model is a government, not an advertiser, metadata is the danger. Knowing who talks to whom, and when, is frequently more dangerous than knowing what they said. The little lock icon was telling users they were safe when they weren't. That bothered me then and it bothers me now.

NIP-04 also used an encryption scheme that cryptographers had been side-eyeing for years. We knew it had to go. The question was what replaced it.

NIP-17, gift wrap, and the beautiful, painful upgrade

The answer the ecosystem converged on was a stack: NIP-44 for modern encryption, NIP-59 for "gift wrapping," and NIP-17 for private DMs built on top of both. This was a genuine leap. Gift wrap doesn't just encrypt the message, it hides the metadata too. The sender is concealed, the event is wrapped in a throwaway key, timestamps are fuzzed. An observer watching the relay sees noise addressed to nobody in particular. This is the real thing NIP-04 only pretended to be.

I want to be clear: NIP-17 was the right move, and I'd make it again. But living through the migration was humbling. "Just switch to the new DMs" is a sentence that hides an enormous amount of pain:

• Everything had to change at once. Sending, receiving, notifications, search, the way clients even find your messages, gift wrap touches all of it. A DM in this model isn't one event, it's a sealed thing inside a wrapped thing, and every app had to learn the whole dance.
• Interop was brutal. For a stretch, whether your "private" message arrived depended on whether the other person's client had implemented the same pieces the same way. We spent real time chasing messages that vanished into the gap between two implementations.
• The old and new worlds coexisted. You can't flip a protocol overnight. For a long while some contacts were NIP-04, some were NIP-17, and the client had to be gracious about both without confusing the user or leaking them back into the insecure path. And this is still a problem on the user experience side that many clients struggle with today.

And there's a deeper headache baked into the design, one that hits group messages hardest. For a gift-wrapped DM to reach you, the sender has to know where you're listening, so NIP-17 leans on DM relay lists, a dedicated event (kind 10050) where you publish the specific relays you read DMs on, and other people's clients are supposed to find that list and deliver there. When it works, it's beautifully decentralized. When it doesn't, and it often doesn't, your message gets sealed up perfectly and delivered to a relay the recipient never checks. It just quietly never arrives. One-on-one, that's frustrating. In a group, it's fatal: every extra member is another DM relay list that has to be published, discovered, and honored correctly, and the odds that someone's is stale or missing climb with every person you add. That's the real reason group DMs on Nostr never felt solid. The math was always working against them.

We got through the one-to-one part. The broader ecosystem moved onto real, metadata-resistant DMs, though some still won't budge on the old NIP-04 implementation. But one-to-one messaging was only ever half of what people actually wanted, and the half we couldn't make feel reliable was exactly the half that mattered most: talking to more than one person at once.

NIP-29 groups, and paying the server tax

Because the thing people really wanted wasn't just DMs. It was community. Group chat. A Discord you actually own. So we turned to NIP-29, relay-based groups, and built toward it, it's still the foundation of a lot of what our chat app Armada does today, and I don't regret the investment.

But NIP-29 came with a tax I didn't love. To run a community, you run a server, a relay configured as the group host. That relay is the authority: it decides who's in, enforces the roles, holds the state. And the messages flowing through it are not end-to-end encrypted. Better than a corporate silo, absolutely. You can leave, you can self-host. But look at what we'd walked back into: a computer in the middle that knows every member, holds every message, and is the final say on who's in charge. We'd spent all that effort killing the metadata problem for DMs, then reintroduced a central authority the moment we wanted more than two people in a room.

I'd be doing this whole story a disservice if I didn't tip my hat to Flotilla and its developer, Hodlbod, who has led the charge on NIP-29 communities for the last couple of years. Armada's relays-as-servers model is borrowed straight from his work, and the whole ecosystem is better for it. He's even gone a step further and made the hard part easier: with Flotilla hosting, you can just buy a NIP-29 server from him instead of standing one up yourself. That genuinely lowers the barrier, and it's a smart, generous thing to offer.

But, and this is my opinion, not a mark against the excellent work: even "just buy a server" is still a concept most people shouldn't have to think about. The average person doesn't want to reason about servers, hosts, or who's running their group's relay. They want to open an app and talk to their people. Every place where the plumbing pokes through is a place we lose someone who isn't a Nostr native yet.

For an internal team tool, none of this matters. For a community that needs to survive pressure, that central relay is exactly the thing an adversary goes after. I kept coming back to the same nagging feeling: we can do better than "trust the server, but a nicer server."

Universes, the one that got away

Somewhere in the middle of all this, we took our own real swing at community. About a year ago we built Universes, a Discord for Nostr: communities, channels, a marketplace, shared resources, the whole thing. We built it on NIP-72 moderated communities, with plenty of back-and-forth about whether relay-based groups (NIP-29) should carry it instead. On paper it had everything.

We never quite got it off the ground. The foundations we had to choose between each pulled in a direction that cost us something we didn't want to give up, and the experience never came together into the thing we could see in our heads. So we made the call to set it down, and we did the thing we always do: we left it open source, out there for anyone to pick up and build on. Universes wasn't wasted effort. It was the experiment that taught us, concretely, what building real community on Nostr actually demands, and what the existing options couldn't give us. Every wall we ran into there is a big part of why we recognized the right answer when we finally saw it. Sometimes the most useful thing an attempt leaves you is a very clear map of where the ground is soft.

Marmot, MLS, and the right tool for a different job

So we looked hard at Marmot, the effort to bring MLS (the same messaging-layer security standard behind serious secure messengers) to Nostr, with implementations like MDK and the White Noise client. It's a serious, long-running effort, we watched it evolve over a couple of years, from its early days as NIP-104, through NIP-EE, into what's now Marmot, and that care shows. On paper it's the gold standard: forward secrecy, post-compromise security, the real cryptographic guarantees. For a small, high-stakes group where every member's safety is paramount, it's genuinely excellent, and I have a lot of respect for the people building it.

But MLS is built around a specific shape of group, and it isn't ours. MLS advances in lockstep: members' keys ratchet forward in an ordered sequence, every membership change is a coordinated commit, and the cost of each change grows with the group. That's a fantastic fit for a secure team of a dozen people. It is a punishing fit for a big, casual, public community where people wander in and out all day, hundreds at a time. The very ratcheting that makes MLS strong for small rooms is doing a lot of work in a large, high-churn one. We prototyped, we thought about it hard, and we came to a conclusion that's important to say out loud: Marmot is excellent. It's just built for a different target than a public, Discord-style community. And picking a tool because it's impressive, rather than because it fits the job in front of you, is a mistake no matter how good the tool is.

And to be clear, none of this is a knock on the Marmot team. They're heads-down, pushing code, doing the slow and careful work that MLS demands, you don't rush forward secrecy, and they're right not to. But we were up against a different clock. We had real communities that needed off centralized chat now, not eventually, people relying on us this year, not whenever a still-maturing spec settled. "Hard problem, done carefully, on its own timeline" is exactly the right way to build MLS; it just collides with "our users can't wait." Respect the work. We simply couldn't wait on it, and even finished, it's built for a smaller room than the one we needed to fill.

That was the moment the whole journey clicked into focus. Every approach so far was excellent at something and wrong for us:

What we needed didn't exist. So we built it.

Concord

Concord is the protocol we landed on for end-to-end encrypted communities, and it's designed around the exact hole every prior step left open. The whole thing rests on one clean idea: delete the computer in the middle.

And I want to be clear about where it came from, because we didn't invent it. Concord is the work of the Vector team, JSKitty and YuurinBee. Interestingly, Vector originally built on Marmot and MLS, walked the same road we did, and eventually reached the same conclusion: for the kind of communities they wanted, they needed a different foundation. So they designed their own, the Concord Protocol. I still remember opening the Vector app for the first time. I used it for about thirty seconds and thought, this is the best Nostr messaging experience I've ever had. I immediately went and told the rest of the team they had to try it. When we dug into how it worked, it was the answer we'd been circling for years. Our own Alex Gleason worked alongside them on version 2 of the protocol, and we ran with it. That's the open web working exactly as it should: two teams, arriving at the same hard problem from different directions, and building the fix together in the open instead of each walling off their own version.

Here's how it works. It splits the three jobs a central server used to do into pieces that need to trust nobody.

• Storage and delivery become dumb, interchangeable relays that only ever see encrypted blobs addressed to meaningless, rotating labels. One misbehaves, you use another.
• "Who's a member?" stops being a list a server enforces and becomes simple key possession: if you can decrypt the room, you're in it.
• "Who's in charge?" stops being a switch a server flips and becomes a signed roster rooted in the owner's identity, authority is math that every member re-checks for themselves. A forged "ban" just gets dropped, because it doesn't trace back to the owner.

You still get the full Discord-style experience, communities, channels, roles, admins, kicks, bans, even voice and video, but the relays, the network, and non-members see only noise. And here's the part that makes me smile after everything above: Concord's base primitive is a stream of NIP-59 gift wraps sharing one key. That painful gift-wrap machinery we fought through back in the NIP-17 days? It became the foundation the community layer is built on.

Concord is honest about its lane, too, the spec itself says so. It doesn't try to replace NIP-17 for your one-on-one DMs, or out-secure Marmot for a six-person cell. It's built for one specific thing the others weren't: large, real, un-shutdownable communities. That clarity is exactly what we were missing for years.

Where Concord is now

This isn't theory anymore, it's shipping. Concord v2 is finalized and running in production. And the truest thing I can tell you about it is this: we shut down our Signal and moved the entire company onto it. Every team chat, every meeting, every conversation we used to have on Signal now happens in our own encrypted communities, on the protocol we built, over infrastructure nobody but us controls. There's no better test of whether you believe your own software than betting your daily work on it, and we did. If it broke, we'd be the ones locked out of our own company. It doesn't break.

We also opened it up. There's now a public Soapbox community anyone can join, a place to talk about our products, and about the wider open web, Nostr, open source, and where all of this is going. Not a support ticket queue, a real room, run on the same encrypted protocol we live in ourselves. The invite's at the bottom of this post.

The ecosystem around Concord is filling in too, which is the part that tells me it's real. A good example: JSKitty just finalized the Vector SDK for Concord v2, the Rust bot SDK that brings the whole bot ecosystem to the protocol. And here's what I love about it: Vector is the Vector team's own Concord client, a sibling to our Armada, and the SDK isn't Armada-only or Vector-only. It works for any Concord client. That's the difference between building on an open protocol and building a walled garden: a bot someone writes for Vector runs in Armada, and vice versa, because the protocol is the thing, not any one app. Concord is already bigger than the team that started it.

And because encrypted communities are exactly the kind of software you should never take on faith, we run a bug-bounty program on Concord. It's already earned its keep. A researcher found a real flaw in the permission system, the role logic checked what a signer had granted but not what they'd revoked, so a member could strip someone else's roles. Serious bug. It was reported and patched the same day (fix 5a655112, by Chad Curtis), and we paid the researcher, hzrd149, a $1,000 bounty and wrote the whole thing up in public. That's the deal we want: you don't have to trust that we handle security responsibly, you can watch us do it, in the open, with receipts, and get paid for making it better.

Why I'm telling you the messy version

I could have written you a clean announcement, "Soapbox now has encrypted communities!", and left out the four dead ends, the migrations that ate weeks, the prototype we walked away from. But that's not building in the open, and honestly it wouldn't be useful to anyone.

Here's what the messy version actually shows: private messaging on an open protocol is hard, and the reason it's hard is the same reason it's worth it. On a closed platform, one company just decides how messaging works and you live with it. On Nostr, we had to earn every guarantee in the open, in public, with real cryptography and real tradeoffs, and anyone can check our work, poke holes in it, and build something better. That's slower. It's also the only version where the answer belongs to you instead of to a company that can change its mind.

And I want to be upfront about one thing: all of this is open beta. It's real, we run our own company on it, but it's early. Concord's newer pieces are still proving out, some of it isn't ratified yet, you'll find rough edges, and we'll hit more walls, we always do. Come in with that expectation, and come in knowing the whole point is that you can watch it get better in the open, and help. But for the first time in this whole journey, the foundation matches the mission: no company in the middle, encryption that's real, and a community that can't be switched off. That was worth the long road.

If you want to see any of it, it's all open:

• Concord protocol: github.com/concord-protocol/concord
• Armada (our chat client built on this): gitlab.com/soapbox-pub/armada

Read it, run it, break it, tell us where we're wrong. That's the whole point.

And if you'd rather just come talk to us, that's the best part: join the Soapbox community and see the whole thing in action. It's where we hang out, where we talk about what we're building, and where anyone can dig into the open web, Nostr, and open source with us. Same encrypted protocol we run our own company on. Come say hi.

Pura vida. 🫂🤙🏻