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 72 hours).
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.
The mesh
Every device running any SDK-embedded app is a potential relay for every other. Platform-native P2P when nearby (Apple Multipeer, Google Nearby), local subnet when on the same network, direct connection over the internet for connectable devices.
A fitness app's users are part of the relay backbone for a marketplace app's users. 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.