How the Offline Protocol works
The Offline Protocol is a transport, identity, and coordination layer for devices that must operate when the network fails. Three primitives, DORS, OfflineID, and Service Discovery, compose into one SDK surface running in production on 350,000+ devices across 80+ countries.
DORS routes encrypted messages across five transports — BLE, WiFi Direct, internet, Reticulum, and Nostr — with automatic failover, 8-hop relay, and confirmed delivery. OfflineID gives every device a self-sovereign Ed25519 identity that verifies with zero connectivity. Service Discovery lets any device advertise a capability and any other device discover and invoke it across the mesh with no server. The three are independent primitives on one surface, not a fixed pipeline.
Three primitives, one surface
Most connectivity stacks assume infrastructure: a tower, an access point, a server that brokers identity and routes traffic. When that infrastructure fails or saturates, every device attached to it goes silent. The Offline Protocol is built the other way around. It assumes the network can fail and keeps devices talking, verifying, and coordinating directly with each other.
It does this with three primitives that are individually usable and composable. Data does not flow through them as a fixed three-stage pipeline; you can route with DORS alone, verify with OfflineID alone, or combine all three. The sections below cover each primitive in depth, then how they compose.
DORS: multi-transport mesh routing
DORS is the transport layer. It runs BLE, WiFi Direct, internet, Reticulum, and Nostr behind one API and moves each message onto whichever enabled path is best right now, scoring transports continuously on live signal strength, congestion, energy budget, and link reliability. Switching between the real-time links completes sub-second, so losing a link is a reroute rather than an outage.
Peering is deliberate. Each device holds a connection budget and scores candidate peers on signal, availability, battery, uptime, stability, and load. Devices in the same cluster connect as members; devices that can see a second cluster connect as bridges, stitching separate pockets of coverage into one routable mesh. Well-charged devices take on relay duty and devices low on energy shed it, so the mesh balances its own load across the fleet.
Sessions are encrypted end to end with MLS (RFC 9420). Relay nodes forward ciphertext they cannot read, and keys never leave the device. How peer-to-peer mesh networking works →
Low-power and ubiquitous. BLE carries peer discovery and small messages, running continuously without meaningful battery cost.
Higher throughput over longer range. WiFi Direct carries bulk data, including chunked transfer up to 100MB, when both ends support it.
When present, the internet is simply the longest link available. Losing it triggers failover to local transports, not an outage.
OfflineID: identity with no authority to call
OfflineID is a self-sovereign identity built on Ed25519. Two devices verify each other device to device, with no certificate authority to query and no registry to reach, so authentication completes even in a jammed or fully disconnected environment. Pairing follows trust-on-first-use, and more than 300,000 OfflineIDs have been issued across the network.
Rotation and revocation are anchored on-chain. When an identity must be retired or rolled, the update propagates across the mesh as nodes touch the internet, giving operators a lifecycle path without a central server issuing it. Private keys are generated and held on the device and are never transmitted.
Because identity is cryptographic and local, field observations can be signed at capture, making records tamper-evident end to end. How offline identity verification works →
Service Discovery: the offline internet
Service Discovery turns the mesh into an invocable network of capabilities. A device advertises what it can do, a sensor feed, a compute service, a data store, and peers up to 8 hops away learn about it through multi-hop routing. Caller and provider verify each other with OfflineID, then request and response travel over the mesh with acknowledgment and retry, exactly like calling an API endpoint. A device five hops away is invocable with no server and no DNS.
This is the only discovery-and-invocation primitive in production that survives losing the internet. How serverless service discovery works →
Reliability, at the protocol level
Reliability is handled below your code. Outgoing messages are fragmented, queued, and polled onto the radio continuously. Each message carries a unique ID and TTL; receivers acknowledge, senders retry on timeout, and relays deduplicate by ID so a message that arrives twice is delivered once. Your application sees a clean contract: sent, then delivered or failed, with hop count and latency attached.
How the primitives compose
In a running deployment the three primitives reinforce each other. DORS carries the traffic and fails over across transports. OfflineID keys the MLS sessions and authenticates both ends of every exchange, so a device is not just reachable but trusted. Service Discovery rides on top, using DORS to route discovery and invocation and OfflineID to verify caller and provider before a capability is exposed.
You can adopt them one at a time. Route encrypted messages with DORS alone, add offline authentication with OfflineID, then open capabilities across the mesh with Service Discovery when your product is ready. The platform exposes all three on one surface. OfflinePay, offline-capable payments on the mesh, is in development.
Going deeper
This page is the narrative overview. For the developer surface, an offline-first SDK with a TypeScript API over a Rust core, the same on iOS and Android, start on the developers page. Full API reference and integration guides live at offlineprotocol.com/docs.
For focused deep-dives on each primitive, see mesh networking, offline identity, service discovery, and telemetry.
Protocol FAQ
What is the Offline Protocol?
Offline Protocol is a transport, identity, and coordination layer for the disconnected edge. It composes three primitives: DORS for multi-transport mesh routing, OfflineID for self-sovereign Ed25519 identity, and Service Discovery for advertising and invoking capabilities across the mesh with no server.
What transports does the protocol use?
DORS runs Bluetooth LE, WiFi Direct, and internet concurrently and switches between them sub-second based on live signal, congestion, energy, and reliability. BLE carries discovery and small messages, WiFi Direct carries bulk data, and internet is treated as one more transport rather than a dependency.
How does the protocol guarantee delivery?
Every message carries a unique ID and TTL. Receivers acknowledge, senders retry on timeout, and relays deduplicate by ID, so a message that arrives twice is delivered once. Routes are bounded to 8 hops, and files up to 100MB move as acknowledged, resumable chunks.
Is the protocol encrypted?
Yes. Sessions are encrypted end to end with MLS (RFC 9420) and keyed to Ed25519 identities. Relay nodes forward ciphertext only, and private keys never leave the device.
Does any part of the protocol require a server?
No. Routing, identity verification, and service discovery all run device to device. When internet is present, the protocol uses it as one transport among several rather than depending on it.
Where can I read the technical documentation?
Full API documentation lives at offlineprotocol.com/docs. This page is the narrative overview; the developer surface, a TypeScript API over a Rust core for iOS and Android, is documented in the developer docs and summarized on the developers page.
