Decentralized
Community
Communication

The Problem with Centralization

Discord launched in 2015 and within a few years became the default gathering place for communities on the internet. Over 500 million registered accounts, hundreds of thousands of active servers, a product that did something genuinely hard well. It made real-time community communication feel effortless. For gamers, developers, artists, educators and study groups, Discord became the town square of the modern internet.

The problem is not that Discord is a bad product. The problem is what its architecture requires of its users. Every message you send, every voice conversation you have, every community you build, every file you share lives on servers owned and operated by a single private company. That company can read your data, and their privacy policy makes clear they collect a great deal of it. They can remove your community without warning. They can terminate accounts based on policy interpretations that shift over time. They can be compelled by any government with jurisdiction to hand over user information. None of this is unusual or surprising. It is simply what centralization looks like in practice.

Over the past few years Discord has faced criticism on all of these fronts. Communities have been removed overnight. Researchers and journalists have documented how behavioral data flows through the platform. The platform has faced legal scrutiny across multiple countries over how it handles user data, particularly for minors. These failures are not the result of bad intentions. They are predictable consequences of building a social platform on centralized infrastructure and then scaling it to hundreds of millions of people who have no real alternative.

Why People Accept These Tradeoffs Anyway

If the privacy and censorship risks are real and documented, why does the platform continue to grow? The honest answer is that the tradeoffs have always felt worth it. Discord is genuinely easy to use. Setting up a server takes two minutes. Inviting friends takes one click. Voice quality is excellent. The app is polished and fast. Nobody has ever built a decentralized alternative that felt as good to actually use, so people keep accepting the privacy costs because the experience available elsewhere is noticeably worse.

That is the real gap this paper addresses. Not "can we build something more private than Discord" — that bar is easy to clear. The actual question is whether we can build something more private and more resilient that people genuinely want to use. Something that respects user data without feeling like a command-line tool from 2008.

Building a more privacy-conscious Discord that still stores everything on company-owned servers does not solve the structural problem. It only delays it. The solution requires a different foundational assumption about where data lives and who controls access to it.

Users as Infrastructure

The idea at the center of this paper is simple. Every computer that runs the application becomes part of the network that is the application. There are no company-owned servers storing messages. There are no central machines routing voice traffic. The network is made entirely of the devices people are already running.

This is not a new concept in computing, but it has never been applied to consumer social software in a form that worked well enough for ordinary people to actually adopt it. What this paper proposes is combining the architectural approach that has made peer-to-peer networks like BitTorrent extraordinarily resilient with the product design philosophy that has made apps like Discord, Notion, and Linear genuinely enjoyable to use.

The AirTag Analogy

The best way to understand what this network looks like in practice is to think about how Apple AirTags work. When an AirTag gets separated from its owner, it does not call home to an Apple data center to report its location. It broadcasts a Bluetooth signal. Any iPhone that happens to be nearby, belonging to any Apple user anywhere in the world, silently detects that signal and sends an anonymous, encrypted location report back to the tag owner through Apple's network.

No single iPhone is "the server" in this transaction. Every iPhone is the network. The network is distributed across hundreds of millions of devices, and it works not because Apple maintains expensive dedicated infrastructure to power it, but because every participating device contributes a small slice of its capability to the whole. Apple's role shrinks to maintaining a small relay layer, and the actual work happens at the edges, on people's own devices.

Now apply that same thinking to community communication. When you turn on your computer and open the application, your machine announces to the network that you are online. It reaches a handful of peers it already knows, and those peers pass the word along to the peers they know. Within seconds, everyone in your communities knows you are online, without a single packet of your personal data passing through infrastructure you do not control.

DISCORD TODAY
  [Your PC] ──────► [Discord Data Center] ◄────── [Friend's PC]
                           │
                    stores your data
                    controls your access
                    can ban your community
                    goes down, you go down

PROPOSED ARCHITECTURE
  [Your PC] ─────────────────────────────── [Friend's PC]
       │                                          │
       └── [User C] ──── [User D] ──── [User E] ──┘
                │                          │
            [User F] ─────────────── [User G]

Every node stores, routes, and serves.
More users online means a stronger, faster, more resilient network.

Why This Flips the Scaling Equation

One of the least intuitive properties of this architecture is what happens as the user base grows. On a centralized platform, growth is a problem to be managed. More users means more servers, more bandwidth costs, more infrastructure to maintain. Discord spent hundreds of millions on infrastructure as it scaled, and that cost has to be paid by someone, which is ultimately why centralized platforms need heavy monetization or significant investor subsidies to survive.

In a peer-to-peer network, growth is a feature rather than a liability. Every new user who joins brings their own bandwidth, their own storage, and their own connectivity. The network does not get slower under load. It gets faster and more resilient. There is no infrastructure bill to pay because the users are the infrastructure. This is not a financing trick. It is a genuinely different relationship between the platform and the people who use it.

How the Network Actually Works

Understanding how a decentralized communication network operates requires thinking through three distinct problems: how peers find each other in the first place, how information spreads once they are connected, and how the system keeps working when individual nodes go offline. Each of these has well-understood solutions drawn from decades of peer-to-peer research and production deployment.

The Three Layers

Layer 1 — Global Peer Discovery via DHT

The first layer is a Distributed Hash Table, or DHT. This is the same technology powering BitTorrent, and it has been running reliably at global scale for over two decades. A DHT is a decentralized lookup system: you can ask it "who is participating in community X?" and it returns a list of peer addresses, with no central server involved in the lookup.

Each peer in the network is responsible for storing information about a small slice of the total key space. When you want to find peers for a specific community, your node computes the community's hash and routes a query through the DHT, hopping from peer to peer until it finds nodes that have stored the relevant peer list. Finding any piece of information in a million-node network takes fewer than 20 hops. The Kademlia algorithm used by BitTorrent has been formally proven to be both correct and efficient, and it is the recommended basis for this system.

Layer 2 — Community Overlay Network

Once your node has found some community peers via the DHT, it forms direct connections with them. Those peers introduce you to other peers in the community, and gradually your node builds up a partial mesh: directly connected to a subset of community members, each of whom is connected to their own subset. You do not need a connection to everyone, just enough paths to reach everyone through a small number of hops.

The community overlay is where messages, presence updates, and community state changes propagate. When any peer produces new information, it fans out through the overlay using a gossip protocol until every online member has received it. The overlay is also self-healing: when a connected peer goes offline, messages route through other paths, and if needed, the DHT finds new peers to replace the lost connection.

Layer 3 — Direct Connections for Voice and DMs

For situations where two specific peers need to communicate directly — a voice call, a direct message, a file transfer — the network establishes an encrypted connection between them using WebRTC. This is the same protocol that powers browser-based video calling. It handles the difficult work of punching through NAT and firewalls automatically. Once the connection is established, data flows directly between the two machines with no intermediary involved at any point.

Peer Discovery, Gossip and Routing

These three mechanisms form the invisible foundation of the network. Getting them right determines whether the system feels fast and reliable or sluggish and unreliable. Each has a well-understood solution, and the work required is integration rather than invention.

How Peers Find Each Other

A new node joining the network faces a bootstrapping problem: it needs at least one other peer to talk to before it can find any peers at all. This is solved through a layered approach that prioritizes the fastest and simplest options first.

The Gossip Protocol

Once peers are connected, information needs to propagate reliably across the community without any coordinator directing the process. When a node receives new information — a message, a presence update, a ban list change — it forwards that information to a random subset of its connected peers. Those peers do the same. The information fans out exponentially until every online member has a copy.

The name comes from how rumors spread in real social networks, which is not a coincidence. The math behind gossip protocols shows that information reaches every node in a network of N peers within roughly log(N) rounds of forwarding. For a community of 10,000 members, complete propagation takes about 13 rounds of gossip, which at typical network latencies translates to well under a second.

  t = 0ms    You send a message
                 │
  t = 5ms    Your node forwards to 6 random peers
                 │
         ┌───────┼───────┐
        A      B      C      D      E      F        │       │       │       │       │       │
  t = 10ms  each peer forwards to 6 more random peers
        │       │
  G H I J K L   M N O P Q R   ...continuing

  t = 30ms   All 1000 online members have received the message.
             Duplicates dropped silently using message IDs.

  No coordinator. No central router. Peers talking to peers.

Bandwidth efficiency is maintained through two mechanisms. Every message carries a unique ID, and nodes track which IDs they have already forwarded, refusing to forward the same message twice. Nodes also use push-pull gossip: rather than forwarding entire messages, they can forward just the message IDs they have seen and let the receiving peer request only the ones it is missing. This cuts redundant traffic significantly in dense networks.

Routing and Self-Healing

Because messages are propagated through the community overlay rather than routed along a specific path, there is no single route that can fail to prevent delivery. If several of your connected peers go offline simultaneously, the message finds alternate routes through other connected nodes. The network heals around failures automatically and continuously. Fault tolerance is not something engineered on top of the system — it emerges naturally from the gossip approach.

Voice Channels Without Servers

Voice is the hardest component of this system to get right, and also the most important one to get right. Discord's voice quality is genuinely excellent, and any alternative that delivers noticeably worse audio will struggle to win users regardless of its privacy properties. The good news is that the tooling available for peer-to-peer voice in 2025 is very mature.

WebRTC Was Designed for This

WebRTC is the protocol standard powering browser-based video calling. It is used by Google Meet, Whereby, Clubhouse, and dozens of other products serving hundreds of millions of users. What makes it particularly well suited here is that WebRTC was designed from the ground up for direct peer-to-peer media exchange. When two peers establish a WebRTC connection, audio flows directly between their devices over a DTLS-SRTP encrypted channel. No company server receives or processes the audio stream. The peer-to-peer nature of WebRTC is the intended design, not a workaround.

The NAT Problem

The biggest obstacle to direct P2P connections is Network Address Translation, or NAT. Most home internet connections involve a router that sits between your computer and the public internet, assigning your machine a private IP address that is not directly reachable from outside your network. This makes it difficult for two peers to connect directly, because neither knows the other's true public address or port.

WebRTC solves this through a process called ICE, Interactive Connectivity Establishment. Each peer contacts a STUN server, which is a lightweight service that tells the peer what its public IP and port look like from outside its NAT. The two peers exchange this information through a signaling channel and attempt a direct connection. This works for the vast majority of home networks.

For the roughly 15% of users behind stricter NAT configurations — corporate firewalls, carrier-grade NAT — a TURN server acts as a fallback relay. Critically, the TURN server cannot read the content because DTLS-SRTP encryption is end-to-end between the two peers. The relay sees only encrypted bytes passing through. Running a small fleet of TURN servers for fallback cases is the minimal infrastructure footprint this platform genuinely requires, and the cost is low because TURN only handles a fraction of connections.

Scaling Voice for Large Channels

A full mesh voice connection works well for small groups. With five people in a voice channel, each person sends audio to the other four and receives from all four. Bandwidth scales quadratically: with ten people, each is sending and receiving nine streams. This becomes impractical above roughly eight participants.

For larger voice channels, the system uses a Selective Forwarding Unit pattern. One peer in the channel — elected automatically based on connection stability and upload bandwidth — acts as a relay hub. Every participant sends audio to this peer, which redistributes it to everyone else. This cuts bandwidth requirements for all other participants from proportional-to-group-size down to a constant cost.

The elected relay changes dynamically. If it disconnects, the remaining participants detect this within a couple of seconds and elect a new relay from among themselves. Users experience a brief reconnection moment at most. Even in relay configuration, audio is end-to-end encrypted: the relay forwards encrypted packets and cannot decrypt them.

SMALL CHANNEL (under 8 participants) — direct P2P mesh
  [A] ◄────────────────────► [B]
   │  ╲                    ╱  │
   │    ╲                ╱    │
   ↓     ╲              ╱     ↓
  [C] ◄────────────────────► [D]
            ╲            ╱
              [E] ◄────► [F]

  Direct connections. Minimal latency. No relay.

LARGE CHANNEL (9 or more participants) — auto-elected relay
  [A] ───┐
  [B] ───┤                     ┌─── [G]
  [C] ───┼──► [Relay Peer] ◄───┼─── [H]
  [D] ───┤     auto-elected    └─── [I]
  [E] ───┤     rotates on
  [F] ───┘     disconnect

  Audio encrypted E2E. Relay cannot read content.

No Accounts. No Passwords. No Database.

Traditional platforms authenticate users against a centralized database of usernames and hashed passwords. This database is a liability. When it gets breached, which the history of internet security suggests is a matter of when rather than if, every user's credentials are potentially compromised at once. The proposed system eliminates this attack surface entirely by replacing account-based identity with cryptographic key pairs.

How Identity Is Generated

On first launch, the application silently generates an Ed25519 key pair. This takes milliseconds and requires no network connection. The private key is stored in the device's secure enclave — the operating system's protected cryptographic storage, the same place that holds biometric data and payment credentials. It never leaves the device and is never transmitted anywhere. The public key becomes the user's permanent identity on the network.

Every message the user sends is signed with their private key. Every peer that receives the message verifies the signature using the public key. This verification is cryptographically guaranteed: only someone who possesses the private key could have produced a valid signature. There is no central authentication server involved. Trust is established mathematically, without any intermediary.

  FIRST LAUNCH (invisible, under 100ms)

  App generates:
    private key  →  stored in system keychain, never leaves device
    public key   →  your identity, shared openly with peers

  Your identity on the network:
    ed25519:7f3a9c2b1e8d4f6a0b3c9d2e5f8a1b4c...

  When you send a message:
    { message + timestamp + your_pubkey }
    └── signed with your private key
       └── signature travels with the message
          └── every receiving peer verifies before accepting
             └── forgery is computationally infeasible

  When you join a community:
    community owner signs { your_pubkey + role + timestamp }
    └── signed credential travels with you
       └── any peer verifies your membership without asking a server

Community Ownership

A community is created by generating a community key pair. The creator holds the private key, making them the cryptographic owner. The community's public key is its permanent identifier: encoded in every invite link, stored by every member, used to verify the authenticity of community settings and moderation actions.

When the community owner makes changes — adding a channel, promoting a member, updating settings — those changes are signed with the community private key. Every peer that receives the change verifies it was made by the legitimate owner without querying any server. Fake community updates are rejected by every peer because the signature does not match.

This has an important implication for resilience. The community does not live on the owner's computer. Every member stores a copy of the community's state locally. If the owner goes offline for a month, the community keeps running on copies held by other members. The owner's private key is only needed when making authoritative configuration changes. Day-to-day operation requires no involvement from the owner at all.

End-to-End Encryption

Messages are encrypted using the Double Ratchet Algorithm, the same protocol that makes Signal conversations secure. The Double Ratchet provides two critical properties. Forward secrecy means that if an attacker compromises your encryption keys today, they cannot use those keys to decrypt messages sent in the past, because each message uses a freshly derived key that is discarded immediately after use. Break-in recovery means that if keys are somehow compromised, future messages automatically re-establish security through a new key exchange. The conversation does not stay compromised indefinitely.

Voice is encrypted via DTLS-SRTP, which WebRTC uses by default. Encryption happens before audio leaves the sender's device, and decryption happens only when it arrives at the recipient. Any relay node or network device between them sees only encrypted bytes and cannot recover the audio content.

Keeping State in Sync

One of the subtler problems in a decentralized communication system is keeping all peers synchronized on shared state. On Discord this is simple: one database, always authoritative. If two users send messages at exactly the same moment, the server picks an order and everyone sees the same thing.

In a peer-to-peer system, there is no single authoritative database. Different peers might have different views of the world at any given instant, depending on what messages have reached them so far. The system needs a principled way to reconcile differences and converge on a consistent shared state without any coordinator.

What a CRDT Is

A Conflict-free Replicated Data Type is a data structure with a mathematical guarantee: any two replicas can be merged into a consistent result regardless of the order in which updates were applied. You do not need to agree on a canonical order of operations. You apply all the operations, and the CRDT's merge function guarantees that every peer who has seen the same set of operations arrives at the same state.

The simplest example is a set that only supports additions, called a G-Set. If two peers add elements concurrently, merging their states is trivial: the merged set contains the union of all elements. More sophisticated CRDTs handle counters, ordered lists, rich text, and key-value maps, all with the same convergence guarantee. The math behind this is well-established and the implementations are production-tested.

  Peer A (London):                    Peer B (New York):
  ┌──────────────────────┐            ┌──────────────────────┐
  │ #general:            │            │ #general:            │
  │   msg:001  "hey"     │            │   msg:001  "hey"     │
  │   msg:002  "sup"     │            │   msg:003  "hello!"  │  ← B wrote
  └──────────────────────┘            └──────────────────────┘
           │                                   │
           └────────────── gossip sync ────────┘
                              │
                              ▼
  Both peers converge:
  ┌───────────────────────────────────────┐
  │   msg:001  "hey"                      │
  │   msg:002  "sup"                      │
  │   msg:003  "hello!"                   │  ordered by logical timestamp
  └───────────────────────────────────────┘

  No server arbitrated this. Math guaranteed convergence.

What Gets Stored as CRDT State

Essentially everything in a community is represented as CRDT state: message history in each channel, the list of channels, the membership roster, role assignments, community settings, and user presence. When a new member joins, their node syncs current CRDT state from nearby peers and immediately has a consistent view of everything that has happened. When an offline member reconnects, their node syncs changes that occurred during their absence and merges them with any local changes made offline.

That last property, offline operation, is worth emphasizing. Because every peer holds a local copy of CRDT state, you can continue using the application without any internet connection. Messages written while offline are stored locally. When you reconnect, they propagate to the rest of the community and merge correctly with everything that happened in your absence. No messages are lost and no state is corrupted. The convergence guarantee holds across arbitrarily long disconnections.

The User Experience Problem

Everything described so far is the easy part. DHTs, gossip protocols, CRDTs, WebRTC NAT traversal — these are all solved problems with mature open source implementations available today. The genuinely hard problem is making a product built on all of this that ordinary people find as natural and pleasant to use as Discord.

This is the reason no previous attempt at a decentralized communication platform has found mainstream adoption. Tox, Retroshare, Jami, Briar — all of them made the engineering work to some degree. None of them solved the experience problem. They exposed network complexity to users. They required manual configuration. They felt like tools built by engineers for engineers, because that is exactly what they were.

The philosophy here is different. The engineering complexity must be completely invisible. A user who downloads this application should never encounter the words "DHT," "NAT traversal," or "CRDT." They should never forward a port, configure a firewall, or understand anything about how the network operates. They open the app, pick a name, click a link, and are in a community. Everything else happens in the background without their knowledge or involvement.

The Silent Boot Sequence

  Application opens
  │
  ├── 1. Generate Ed25519 keypair (first launch only, 40ms)
  │       └── Store private key in OS secure keychain
  │
  ├── 2. Broadcast mDNS discovery on local network
  │       └── Instant peer discovery if any known peers on same WiFi
  │
  ├── 3. Contact STUN server to determine NAT type
  │       └── Decide whether direct P2P or TURN relay is needed
  │
  ├── 4. Register presence in DHT
  │       └── Other peers can now discover this node
  │
  ├── 5. Sync communities
  │       └── CRDT merge of state changes since last session
  │
  └── 6. Begin listening for incoming connections

  Total time on typical broadband: under 1 second
What the user sees: a loading indicator, briefly.

Onboarding in Three Screens

The entire onboarding flow has a hard limit of three screens. Any complexity that cannot fit inside three screens gets hidden behind a settings menu that most users will never open.

The Invite Link

Discord's invite link is one of the most effective viral growth mechanisms in consumer software history. One click and you are in a new community. The proposed platform replicates this experience exactly, but the link encodes different information underneath.

mesh://join?c=7f3a9c2b&peers=185.12.44.1,94.23.11.8&r=relay.app.io
                    │                    │                     │
                    │                    │                     └── TURN relay fallback
                    │                    └── Bootstrap peer IPs from invite sender
                    └── Community public key (short form)

  User experience after clicking:
    App installs (first time) or opens (returning)
    Community key and bootstrap peers decoded from link
    Connects to listed peers
    Community state syncs in background
    User lands in the community, already connected

  From the user's perspective: click link, you're in.

Three Layers of Interface Depth

The design uses progressive disclosure. Complexity exists but is hidden until someone goes looking for it. The vast majority of users will only ever see the first layer.

Recommended Technology Stack

Every component recommended here is open source, in active development, and has demonstrated reliability at production scale. The engineering effort required is integration work, not protocol research. Nothing needs to be invented from scratch.

The Minimal Server Footprint

In the spirit of honesty: this platform is not 100% serverless on day one. A small amount of infrastructure is genuinely required, and it is worth being specific about what it does and why it exists.

None of these components store messages, community data, voice audio, or user personal information. They are infrastructure glue, not data silos. Each can be self-hosted by technically sophisticated users or communities who want zero dependence on the application developer's infrastructure.

Hard Problems and Honest Mitigations

This paper would be misleading if it presented the proposed architecture as solving every problem cleanly. Several genuine engineering challenges exist and deserve honest treatment rather than hand-waving. Each one is solvable, but none of them are trivial, and building this product requires understanding where the difficult work actually lives.

What Has Been Tried Before

The history of decentralized communication software is a long record of technically competent products that failed to find mainstream adoption. Understanding why they failed is more useful than cataloguing their features.

A Note on Matrix

Matrix deserves separate treatment because it is the most technically serious prior attempt at decentralized communication. Matrix's federated architecture means anyone can run a Matrix homeserver, and homeservers talk to each other to form a network. This is meaningfully better than centralized Discord. But it still requires someone to run a server, which means there is still a point of control and a point of failure. A Matrix server can be taken down, legally compelled to hand over logs, or simply shut down when someone stops paying the hosting bill.

The proposed architecture goes further: no server required at all, just users. Additionally, Matrix's primary client Element has improved substantially but still falls short of Discord in terms of raw polish and ease of use. The bar to clear is Discord's UX, not Element's.

Build Roadmap

The proposed implementation is structured in phases, each of which delivers a working and testable product. No phase requires the completion of a later phase to provide value. This matters because it means early testing with real users can begin within a few months, and the architecture can be validated against real usage before committing to the full build.

A Private Internet, Shaped Like Discord

Every technical component described in this paper exists today, is open source, and has been proven to work at scale in real production environments. The DHT algorithms proposed for peer discovery are the same ones that have routed billions of BitTorrent connections for over two decades. The WebRTC voice protocols are embedded in every modern web browser and used daily by hundreds of millions of people. The CRDT data structures handling distributed state consistency are used in collaborative tools serving millions of users. The cryptographic primitives providing end-to-end privacy are the ones protecting Signal conversations globally.

The challenge in building this is not engineering research. Nobody needs to invent a new protocol or prove a new theorem. The challenge is product design and integration: taking all these mature, well-understood components and assembling them into something that ordinary people find as natural to use as Discord, without any of the privacy compromises Discord requires of its users.

That is the gap in the market. Tox proved P2P communication works. Jami proved DHT-based discovery works. Matrix proved that a meaningful portion of the population wants an alternative to centralized platforms. None of them proved you can do all of this and deliver a product that a non-technical user finds genuinely enjoyable. That proof of concept has not been built yet, which is what makes it worth building now.

The timing is favorable in a way it was not five years ago. Public trust in centralized platforms has declined as data breach after data breach, ban after ban, and policy change after policy change have made the costs of centralization concrete rather than theoretical. The audience for a genuinely private, genuinely resilient community platform exists and is growing.

What that audience has been waiting for is something that does not ask users to care about the underlying technology in order to benefit from it. A platform whose privacy properties are a consequence of its architecture, not a feature the user has to consciously enable. Something unstoppable that happens to feel like the apps people already love.

That is what this paper proposes to build.