Announcing Concord

Every group chat you have ever used has a computer in the middle. It holds every message, knows every member, and is the final authority on who can do what. You trust it to stay online, to keep your data private, and to never turn on you.

It can be subpoenaed, hacked, sold, or switched off. And when it is, your community dies with it — not just the history, but the room itself: the member list, the roles, the shared context that made it a place rather than a group of contacts.

The usual decentralised answer is to let people run their own copy of that computer. This helps with whose computer it is, and not at all with the fact that there is one. The operator still reads every message, still holds the member list, and still decides who is an admin. You have not removed the trusted party; you have only changed which one you are trusting.

Concord deletes that computer

Not literally. Concord runs overNostr, and ordinary relays still carry every message — Concord simply assumes they are run by strangers. What it deletes is the computer that mattered: the one that could read your messages, hold your member list, and decide who is in charge. It takes those three jobs and splits them into pieces that need to trust nobody.

Storage and delivery become dumb, interchangeable relays. They only ever see encrypted blobs addressed to rotating, meaningless labels. A relay carrying ten Concord communities cannot partition its own storage by community, let alone read one. If one relay misbehaves, you use the others.

Membership becomes key possession. If you can decrypt the room, you are in it. There is no list to enforce, to leak, or to be compelled to produce — and no request that anyone can deny.

Authority becomes a signed roster rooted in the owner's own key. Every grant and every ban chains back to an identity the community's id commits to by construction. Each client folds that chain independently and reaches the same verdict.

The result is full Discord-style moderation — owners, admins, roles, kicks, and bans — where authority is a signed list everyone can verify, and messages are sealed so that relays, network observers, and non-members see only noise.

Enforcement by rejection

The idea that makes this work is worth stating plainly, because it inverts an assumption most software is built on. There is no server to stop anyone from publishing anything. Instead, everyone elsedrops what does not qualify.

A forged ban is not blocked at the door. It is published, propagated, and then discarded by every honest client, because it does not trace back to the owner. A demoted admin's action is dropped the moment a verifier holds the demotion that superseded their grant. A removed member can construct a perfectly well-formed key rotation, and every member opens the seal, folds the roster, and throws it away.

This sounds weaker than server enforcement, and in one narrow way it is: a misbehaving member can generate noise. It is stronger in every other way, because there is no privileged party who can be compelled, bribed, or breached into granting authority the owner never signed.

Removal that actually removes

Most encrypted group chats are vague about what happens when you throw someone out. Concord is specific, because it separates three things that usually get conflated.

Stripping a role revokes authority. The person is still a member. A kick asks their client to leave — andcooperative is the honest word for it, because a defiant client still holds every key. Only rotating the keys enforces anything: the community rolls to a new key handed to whoever is left, and everything afterward is unreadable to the person removed.

Because a community's identity is a commitment to its owner rather than to its keys, it can change all its locks without becoming a different community. Bans, in Concord, are all three layers in the order their guarantees arrive: silence first because that is instant and free, severance last because it is heavy and asynchronous. A partially propagated removal degrades to a weaker removal, never to a broken one.

What ships today

A protocol with one implementation is a format. Concord launches with three, built by separate teams against the same specification.

Armada, by Soapbox, is the full Discord-shaped client: threads, voice and video, custom emoji and themes, roles, and a Discord bridge that mirrors a channel both ways so nobody has to move all at once. It speaks Concord alongside other community protocols, so one key carries you across the ecosystem.

Vector, by Vector Privacy, is a native messenger built around a privacy-by-principle philosophy — no KYC, encrypted local storage, an optional Tor transport, and in-chat mini-apps. Vector co-authored the specification.

Accordion, by hzrd149, runs entirely in the browser with no backend, built on the applesauce toolkit. It is the smallest of the three and the best answer to "how hard is this to implement?"

And things built on top

The tooling arrived alongside. Thevector_sdk crate handles keys, relays, streams, and encryption so you write handlers instead of cryptography. Derek Ross has shippedShanty, a 24/7 generative lo-fi radio bot for live channels with a Wavlake and Fountain jukebox; anauto-moderation bot; andPrivate Events, a full application using Concord as private, serverless application infrastructure rather than as a messenger.

Bots on Concord are worth a sentence of their own, because the shape is genuinely different. There is no API to be granted, no token to be revoked, and no webhook to register. A bot holds a key like any member and moderates with exactly the rank its role gives it. Nothing in the protocol privileges a human over a program — and nothing lets a platform cut your bot off, because there is no platform.

The honest limits

Concord's specification names its own weaknesses, and so should its announcement.

It is not ratcheted. If someone obtains a channel key for an epoch, every message in that epoch is readable to them. Rotation protects the future, not the past. This is a deliberate trade: MLS and the Double Ratchet advance in lockstep, which is the right design for six people planning something sensitive and the wrong one for six hundred people with channels and moderators, half of them offline at any moment. If your group is the former, useMarmot.

Expiry and kicks are cooperative. A member who could read something could always have copied it, and no protocol changes that. Disappearing messages are hygiene against a seized device, a compromised key, or an archived relay — not protection from the people in the room with you.

There is no succession. Binding a community's identity to its owner's key makes ownership unforgeable and also makes it unrecoverable. A lost owner key cannot be replaced. The clean exit is dissolution.

And traffic analysis is real. Relays see volume, size, and timing, and a channel's address is stable until somebody is removed. Concord hides what you say and who is in the room; it does not hide that you connected.

Read it, then take it apart

Concord is eight short documents, MIT licensed, and readable in an evening. They are the source of truth, and they are where design questions get settled — in the open, in a repository anyone can file an issue against.

If you want to understand it, start withhow it works. If you want to trust it, start with the threat model. If you want to build on it, start with theimplementer checklist, which collects the requirements that bite.

And if you just want to use it, pick a client. That is rather the point: the community is yours either way.