How it works
The relay mesh is shared across all participating applications. The application namespaces are isolated. These two properties together are what make the economics work.
The relay doesn't read
If messages are encrypted before they leave the sending device, a relay is just a pipe. It receives an opaque blob, identifies the recipient by a hash, and forwards it. It cannot read the content. The relay infrastructure for one app is identical — in every technical respect — to the relay infrastructure for every other app.
Cryptographic, not by access control
Applications sharing relay infrastructure are isolated cryptographically. Destination hashes — the routing identifiers on every packet — are computed as:
A relay cannot determine which application a packet belongs to, cannot inject into any namespace without knowing the identifier, and cannot correlate traffic across namespaces. Hashes rotate every hour, limiting traffic-analysis windows.
The node layer
The backbone. One Docker container. Always on. Always connectable. Never holds a decryption key.
Packet relay and store-and-forward
Routes encrypted packets to connected clients. Queues blobs for offline recipients with a configurable TTL (default 30 days).
Push notification forwarding
When a message arrives for an offline device, fires a silent content-free wake signal via APNs, FCM, or Web Push. The signal contains no message content.
Encrypted media storage
Accepts and serves opaque encrypted blobs. Never holds a decryption key. The decryption key travels through the message channel, never through the Node API.
Prekey directory
Stores public pre-key bundles for PQXDH first contact. Allows strangers to initiate an encrypted session without prior communication.
Relay federation
Nodes peer over a mutual cryptographic handshake and forward packets for each other. Open mode admits any relay that proves key possession — rate limits, hop caps, and deduplication are the abuse boundary. One bootstrap entry joins the mesh.
DNS-free relay location
Relays sign a self-certifying address record and gossip it, so a node finds and reaches any other by key — never by domain name. Packets route straight to the recipient’s home relay instead of flooding the mesh; NAT-bound relays are reached by transit through a public anchor, and a bounded search over the gossip topology bridges even both-ends-NAT pairs.
Onion-routed transit
Optional per-hop onion encryption (X25519 → AES-256-GCM sealed boxes). Each relay on a transit path peels only its own layer — it learns the next hop and nothing else: not the packet, not the destination hash, not the final relay. Path selection inserts extra hops so a non-adjacent relay never learns the destination.
Username directory
Optional per-namespace handles (@alice) with a configurable ownership policy: signed-transfer by default — a username is yours until you cryptographically sign it over — or last-writer-wins for apps that want loose handles.
The mesh
Devices on the same network already message each other peer-to-peer: the LAN bearer discovers peers on the subnet and delivers directly, so established conversations survive losing the relay — or the entire internet. On-site and air-gapped deployments (human or machine-to-machine) work today.
The further tiers — platform-native proximity P2P (Apple Multipeer, Google Nearby), direct internet paths — are specified and demand-gated. Every device running any SDK-embedded app is a potential relay for every other; the infrastructure is built by participation, not by investment.
Strengthens with adoption
At low mesh density, a node sees one end of a path — Alice's node sees Alice, Bob's sees Bob, neither sees both. At high density, messages route through multiple independent nodes; no single relay can correlate sender and recipient.
Every active device also generates a constant stream of random encrypted chaff packets regardless of real activity. A node operator cannot distinguish real messages from noise or infer from traffic volume whether a conversation is active.
The bootstrap problem, honestly
The whitepaper states this directly. Each stage has independent value.
The floor
The node layer delivers working E2EE relay infrastructure on day one, before the mesh exists. One developer, one node, one user base — that is a real outcome.
The ceiling
The distinctive value is in the mesh layer, and the mesh requires adoption. Multi-node routing, ambient relay capacity, and privacy-improves-with-scale are all functions of network participation.
The dynamic
This is BitTorrent honestly applied. BitTorrent had no peers for the first torrent. What the architecture ensures is that each stage of adoption delivers real, usable value. The ceiling scales with adoption.