How DORS failover works

TL;DR

DORS, Offline Protocol's transport layer, continuously scores BLE, WiFi Direct, internet, Reticulum and Nostr and sends each message over the best path. The same scoring loop handles failover, with no separate mode. Messages relay up to 8 hops, and relays forward ciphertext only.

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 can run BLE, WiFi Direct, internet, Reticulum, and Nostr under one router, and the protocol’s job is to keep messages moving across whichever combination of those transports is best right now.

DORS routing across BLE, WiFi Direct, internet, Reticulum, and Nostr

DORS does not pick one transport and hope. It scores every enabled transport 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 is automatic, with hysteresis and a cooldown so routes do not flap, and the application above it sees a delivery, not an outage.

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 100 MiB with per-chunk acknowledgment and resume. The internet, when it exists, is simply the longest link available.

DORS automatic failover

The important design decision is that DORS has 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.

8-hop relay and delivery acknowledgment

Messages in DORS carry a unique ID and a TTL and relay up to 8 hops through intermediate devices, and receivers acknowledge them. Failover across transports handles the local link; multi-hop relay handles reach. 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.

Battery-aware relay duty

DORS distributes relay duty by charge level. Well-charged devices take on forwarding work, and devices below an energy threshold shed it automatically. A mesh made of phones has a constraint a mesh made of routers does not: energy. The fleet balances its own load, which is what makes an 8-hop relay path viable on hardware people carry in their pockets.

End-to-end encryption across relay hops

Relay devices cannot read the messages they carry. Sessions are encrypted with MLS (RFC 9420) over Ed25519 identities, and relay nodes forward ciphertext only, so none of this routing flexibility costs confidentiality. 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.

DORS in production

This is not a lab design. DORS runs in production on a network that has reached 350,000+ devices across 140+ countries, with 11,500+ local networks active this month, 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.