I am a huge admirer of the open-source ethos. There is something magical about how thousands of strangers can self-organize to build world-changing software like Linux or Kubernetes. These communities thrive on rough consensus, shared goals, and the freedom to fork if visions diverge.
But there is a disconnect. While we have mastered distributed collaboration for our code (Git), the tools we use to talk to each other are still stuck in a rigid, hierarchical past.
Even in the healthiest, most democratic Discord server or Slack workspace, the software forces a power imbalance. Technically, one person owns the database, and one person holds the keys. The community remains together because of trust, yes—but the architecture treats it like a dictatorship.
The Problem: Benevolent Dictatorships
Most online communities I am part of are benevolent. The admins are friends, the rules are fair, and everyone gets along. But this peace exists despite the software, not because of it.
Under the hood, our current platforms rely on a "superuser" model. One account has the DELETE privilege. One account pays the bill. One account owns the data.
This works fine until it doesn't. We have seen it happen with Reddit API changes, Discord server deletions, or just a simple falling out between founders. When the social contract breaks, the one with the technical keys wins. Always.
I call this experiment The Clubhouse Protocol. It is an attempt to fix this alignment—to create a "Constitution-as-Code" where the social rules are enforced by cryptography, making the community itself the true owner of the platform.
This post is part of a series of ideas from my backlog—projects I have wanted to build but simply haven't found the time for. I am sharing them now in the hope that someone else becomes inspired, or at the very least, as a mental note to myself if I ever find the time (and skills) to pursue them.
Disclaimer: I am not a cryptographer. The architecture below is a napkin sketch designed to explore the social dynamics of such a system. The security mechanisms described (especially the encryption ratcheting) are illustrative and would need a serious audit by someone who actually knows what they are doing before writing a single line of production code.
The Core Concept
In the Clubhouse Protocol, a "Channel" isn't a row in a database table. It is a shared state defined by a JSON document containing the Rules.
These rules define everything:
- Who is allowed to post?
- Who is allowed to invite others?
- What is the voting threshold to change the rules?
Because there is no central server validating your actions, the enforcement happens at the client level. Every participant's client maintains a copy of the rules. If someone tries to post a message that violates the rules (e.g., posting without permission), the other clients simply reject the message as invalid. It effectively doesn't exist.
The Evolution of a Community
To understand why this is powerful, let's look at the lifecycle of a theoretical community.
Stage 1: The Benevolent Dictator
I start a new channel. In the initial rule set, I assign myself as the "Supreme Owner." I am the only one allowed to post, and I am the only one allowed to change the rules.
I invite a few friends. They can read my posts (because they have the keys), but if they try to post, their clients know it's against the rules, so they don't even try.
Stage 2: The Republic
I decide I want a conversation, not a blog. So, I construct a start-vote message.
- Proposal: Allow all members to post.
- Voting Power: I have 100% of the votes.
I vote "Yes." The motion passes. The rules update. Now, everyone's client accepts messages from any member.
Stage 3: The Peaceful Coup
As the community grows, I want to step back. I propose a new rule change:
- Proposal: New rule changes require a 51% majority vote from the community.
- Proposal: Reduce my personal voting power from 100% to 1 (one person, one vote).
The community votes. It passes.
Suddenly, I am no longer the owner. I am just a member. If I try to ban someone or revert the rules, the community's clients will reject my command because I no longer have the cryptographic authority to do so. The community has effectively seized the means of production (of rules).
The Architecture
How do we build this without a central server?
1. The Message Chain
We need a way to ensure order and prevent tampering.
- A channel starts with three random strings: an
ID_SEED, aSECRET_SEED, and a "Genesis ID" (a fictional previous message ID). - Each message ID is generated by HMAC'ing the previous message ID with the
ID_SEED. This creates a predictable, verifiable chain of IDs. - The encryption key for the message envelope (metadata) is derived by HMAC'ing the specific Message ID with the
SECRET_SEED.
This means if you know the seeds, you can calculate the ID of the next message that should appear. You can essentially "subscribe" to the future.
2. The Envelope & Message Types
The protocol uses two layers of encryption to separate governance from content.
The Outer Layer (Channel State):
This layer is encrypted with the key derived from the SECRET_SEED. It contains the message metadata, but crucially, it also contains checksums of the current "political reality":
- Hash of the current Rules
- Hash of the Member List
- Hash of active Votes
This forces consensus. If my client thinks "Alice" is banned, but your client thinks she is a member, our hashes won't match, and the chain will reject the message.
The Inner Layer (The Payload):
Inside the envelope, the message has a specific type:
-
start-vote/cast-vote: These are visible to everyone in the channel. Governance must be transparent. -
mutany: A public declaration of a fork (more on this later). -
data: This is the actual chat content. To be efficient, the message payload is encrypted once with a random symmetric key. That key is then encrypted individually for each recipient's public key and attached to the header. This allows the group to remove a member simply by stopping encryption for their key in future messages.
3. Storage Agnosticism
Because the security and ordering are baked into the message chain itself, the transport layer becomes irrelevant.
You could post these encrypted blobs to a dumb PHP forum, an S3 bucket, IPFS, or even a blockchain. The server doesn't need to know what the message is or who sent it; it just needs to store a blob of text at a specific ID.
The Killer Feature: The Mutiny
The most radical idea in this protocol is the Mutiny.
In a standard centralized platform, if 45% of the community disagrees with the direction the mods are taking, they have to leave and start a new empty server.
In the Clubhouse Protocol, they can Fork.
A mutiny message is a special transaction that proposes a new set of rules or a new member list. It cannot be blocked by existing rules.
When a mutiny is declared, it splits the reality of the channel.
- Group A (The Loyalists) ignores the mutiny message and continues on the original chain.
- Group B (The Mutineers) accepts the mutiny message. Their clients apply the new rules (e.g., removing the tyrannical admin) and continue on a new fork of the chain.
Crucially, history is preserved. Both groups share the entire history of the community up until the fork point. It’s like git branch for social groups. You don't lose your culture; you just take it in a different direction.
Implementation Challenges
As much as I love this concept, there are significant reasons why it doesn't exist yet.
The Sybil Problem: In a system where "one person = one vote," what stops me from generating 1,000 key pairs and voting for myself? The solution lies in the protocol's membership rules. You cannot simply "sign up." An existing member must propose a vote to add your public key to the authorized member list. Until the community votes to accept you, no one will encrypt messages for you, and your votes will be rejected as invalid.
Scalability & The "Header Explosion": The encryption method described above (encrypting the content key for every single recipient) hits a wall fast. If you have 1,000 members and use standard RSA encryption, the header alone would be around 250KB per message. This protocol is designed for "Dunbar Number" sized groups (under 150 people). To support massive communities, you would need to implement something like Sender Keys (used by Signal), where participants share rotating group keys to avoid listing every recipient in every message.
The "Right to be Forgotten": In an immutable, crypto-signed message chain, how do you delete a message? You can't. You can only post a new message saying "Please ignore message #123," but the data remains. This is a privacy nightmare and potentially illegal under GDPR.
Key Management is Hard: If a user loses their private key, they lose their identity and reputation forever. If they get hacked, there is no "Forgot Password" link to reset it.
The Crypto Implementation: As noted in the disclaimer, rolling your own crypto protocol is dangerous. A production version would need to implement proper forward secrecy (like the Signal Protocol) so that if a key is compromised later, all past messages aren't retroactively readable. My simple HMAC chain doesn't provide that.
Why it matters
Even if the Clubhouse Protocol remains a napkin sketch, I think the question it poses is vital: Who owns the rules of our digital spaces?
Right now, the answer is "corporations." But as we move toward more local-first and peer-to-peer software, we have a chance to change that answer to "communities."
We need more experiments in distributed social trust. We need tools that allow groups to govern themselves, to fork when they disagree, and to evolve their rules as they grow.
If you are a cryptographer looking for a side project, feel free to steal this idea. I just want an invite when it launches.
Top comments (0)