Offline service discovery: the internet without infrastructure
Service discovery is how devices find and invoke each other's capabilities with no DNS, no registry, and no server. Offline Protocol runs the only such primitive in production, so a request reaches a provider across the mesh with zero connectivity.
What is service discovery?
On the internet, finding a service means asking infrastructure: DNS resolves a name, a load balancer picks a server, a registry lists what exists. Every step assumes connectivity to something central.
Offline service discovery inverts the model. A device announces what it can do, a camera feed, a translation model, a data store, and nearby devices learn about it directly. Discovery information propagates hop by hop through the mesh, so a capability is findable well beyond radio range of its host.
Discovery alone is not enough; the point is invocation. A useful primitive lets the discovering device call the capability and get an answer back, with the same reliability guarantees an API client expects.
Diagram: peer-to-peer service discovery without a server, where a phone advertises a capability across the mesh and a dashboard discovers, authenticates, and invokes it request/response with no DNS and no internet.
One capability, two surfaces: unit-19 registers thermal-cam.v1 and the announcement propagates hop by hop through the mesh. A console three hops away discovers it, authenticates with OfflineID, and invokes it like an API endpoint, request and response riding the same encrypted session.
How Offline Protocol implements it
Service Discovery is the coordination layer of the platform, running over the DORS mesh:
Any device publishes a named capability with a request/response contract. No registration server; the announcement lives in the mesh.
Peers up to 8 hops away learn of the capability through multi-hop routing. Discovery works identically with or without internet present.
Caller and provider verify each other with OfflineID (Ed25519, trust-on-first-use) and open an MLS-encrypted session. No CA lookup, no round-trip to a server.
Request and response travel over the mesh with acknowledgment, retry, and deduplication. A device five hops away is invocable like an API endpoint.
This is the only discovery-and-invocation primitive in production that survives losing the internet.
The mechanics
- Registration
- A provider registers a service with an ID, a version, and key-value capability metadata: the languages a translator supports, the format a sensor emits. The registration lives in the mesh itself; there is no registry server to keep alive.
- Discovery query
- A consumer broadcasts a query for one service ID or everything in range. Each provider answers with its peer ID, version, capabilities, and hop distance, so the consumer picks the closest or most capable before sending a request.
- Invocation
- Requests and responses are correlated by ID, so many invocations run at once, each inheriting the transport's acknowledgment, retry, and deduplication.
- A familiar model
- The programming model is the one every developer already knows from HTTP clients, running on a network that does not need the internet to exist.
An mDNS alternative that crosses hops and transports
Developers searching for local-network discovery usually land on mDNS, Bonjour, or DNS-SD. Those protocols answer a narrower question: what is on this WiFi segment right now. They stop at the subnet boundary, they assume everyone shares an access point, and they say nothing about calling the service they found.
Service Discovery is built for the case where there is no shared network at all. Announcements travel over BLE and WiFi Direct links on the DORS mesh, cross transports mid-route, and reach peers up to 8 hops away. Discovery and invocation are one primitive: finding a service and calling it use the same authenticated, encrypted session machinery.
The result behaves like a serverless API layer for physical space. It is part of the same three-layer platform as transport and identity, and it ships in the same TypeScript SDK, so registering a service is application code, not infrastructure work.
What runs on an offline internet
A device with a loaded model registers an inference service. Nearby devices discover it and send classification or generation requests without cloud access.
Sensors register as data providers for temperature, air quality, or position. Nearby devices discover and query them in real time, an ad-hoc sensor network with zero infrastructure.
Devices that have cached maps, articles, or firmware updates register as content providers. Others fetch from the nearest peer, a CDN made of the devices around you.
When infrastructure is down, devices register what they can offer: medical supplies, shelter availability, communication relay. Response teams discover what is available in their vicinity.
One device registers a compute service; others discover it, send work units, and collect results. A computation split across the mesh instead of a data center.
Live polling, file drops, local chat rooms, and schedule lookups register as services at a conference or stadium. Attendees use them without an app server or internet connection.
Where it applies
- Agent coordination
- Agent-to-agent invocation with no broker in the middle.
- Autonomous vehicles
- Capability sharing between vehicles across the fleet.
- Venues
- Services published directly onto the crowd's mesh.
- Foundations
- Runs on the DORS mesh transport and authenticates with OfflineID.
Service discovery FAQ
How is this different from mDNS or Bonjour?
mDNS discovers names on a single local network segment and stops there. Service Discovery propagates capability announcements across multiple hops and multiple transports, and pairs discovery with authenticated request/response invocation.
What does invocation latency look like?
Per-hop forwarding time with no server round-trip. A one-hop invocation is direct-link speed; each additional hop adds relay forwarding only.
Can a capability be restricted to specific callers?
Yes. Every invocation is OfflineID-authenticated, so providers decide per-identity who may call. Sessions are MLS-encrypted end to end.
Is this in production or a research protocol?
In production, on the same network that carries 350,000+ devices across 80+ countries and 10,000+ active clusters.
Do providers need to be directly connected to callers?
No. Discovery queries propagate through the mesh with the same multi-hop routing as regular messages, so a provider several hops away, with no direct radio contact to the caller, is still discoverable and invocable.
How do devices find each other without a server?
Each device announces its capabilities to nearby peers, and those announcements propagate hop by hop through the mesh. There is no registry server: the announcement itself, carried by the devices, is the registry.
Is there an SDK for peer-to-peer service discovery?
Yes. The React Native SDK exposes a TypeScript API for registering, discovering, and invoking services over the mesh, running on a Rust core on iOS and Android.
