How DORS failover works
Most networking stacks treat connectivity as binary. You are online or you are not, and when the link you configured goes away, your application gets an error. DORS, the transport layer of Offline Protocol, treats connectivity as a portfolio. Every device runs BLE, WiFi Direct, and internet concurrently, and the protocol’s job is to keep messages moving across whichever combination of those transports is best right now.
Three transports, one router
Each transport has a different physics. BLE is low-power and present on effectively every phone, so it carries peer discovery and small messages. WiFi Direct spans longer distances at higher throughput, so it carries bulk data, including chunked file transfer up to 100MB with per-chunk acknowledgment and resume. The internet, when it exists, is simply the longest link available.
DORS does not pick one and hope. It scores all three continuously on live signal strength, congestion, energy budget, and link reliability, and it routes each message over the best path available at that moment. When a path degrades, traffic moves. The switch completes sub-second, so the application above it sees a delivery, not an outage.
Failover is the default path, not an exception handler
The important design decision is that there is no “failover mode.” The same scoring loop that picks the best transport on a good day is the mechanism that abandons a dying one on a bad day. Losing the internet does not trigger special-case code. It just removes one candidate from a list that still has two entries.
That is why the platform describes failover as automatic rather than configured. There is nothing to configure. A message that started its life expecting an internet link can complete over a chain of BLE and WiFi Direct hops without the sender’s code changing at all.
Eight hops, confirmed delivery
Failover across transports handles the local link. Multi-hop relay handles reach. Messages in DORS carry a unique ID and a TTL and relay up to 8 hops through intermediate devices. Receivers acknowledge, senders retry on timeout, and relays deduplicate by ID, so a message that arrives twice is delivered once. The application sees a clean contract: sent, then delivered or failed, with hop count and latency attached.
Peering underneath this is deliberate. Every device holds a connection budget and scores candidate peers on signal strength, availability, battery, uptime, stability, and load. Devices in the same cluster connect as members, and devices that can see a second cluster connect as bridges, which is how separate pockets of coverage merge into one routable mesh.
The battery is part of the routing table
A mesh made of phones has a constraint a mesh made of routers does not: energy. DORS distributes relay duty by charge level. Well-charged devices take on forwarding work, and devices below an energy threshold shed it automatically. The fleet balances its own load, which is what makes an 8-hop relay path viable on hardware people carry in their pockets.
Encrypted through every hop
None of this routing flexibility costs confidentiality. Sessions are encrypted with MLS (RFC 9420) over Ed25519 identities, and relay nodes forward ciphertext only. Keys never leave the devices that hold them, so a message can cross eight intermediate phones and change transports mid-route without any of those phones being able to read it.
Why it matters
This is not a lab design. DORS runs in production on 350,000+ devices across 80+ countries, with 10,000+ active clusters, and it is the transport under every other layer of the platform. If your systems operate where connectivity degrades, the difference between “the link dropped” and “the message rerouted” is the difference between an incident and a log line.
Read more on how the mesh works, or talk to us about running it against your use case.