Offline service discovery
A device announces what it can do, the announcement travels hop by hop through the mesh, and any peer up to 8 hops away can call it like an API endpoint. Service discovery, our invocation layer, does this in production with no DNS, no registry, and no server.
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.
unit-19 announces thermal-cam.v1, and a console three hops away calls it.
What is service discovery?
Every lookup needs a server. On the internet, a name goes to DNS, a request goes through a load balancer, and a listing lives in a registry. All of it sits somewhere central. Lose the link and there is no way to find anything.
A device announces what it can do. A camera feed, a translation model, a data store. Neighbours hear it directly and each one passes it on, so a capability is findable well beyond the radio range of the device that offers it.
Then you call it. Discovery hands back something you can use right away. The device sends a request over the mesh and gets a response, acknowledged, retried, and encrypted end to end, the way an API call should behave.
Advertise, discover, authenticate, invoke
Service discovery runs on the DORS mesh and authenticates with OfflineID, so it inherits multi-hop routing and encrypted sessions rather than rebuilding them. Four steps take a capability from one device to a call from another.
- Advertiseunit-19 publishes thermal-cam.v1 with a request/response contract. There is no registration server: the announcement lives in the mesh and ripples outward, hop by hop.
- DiscoverA console three hops away asks for what is in range. Every provider answers with its version, its capabilities, and its hop distance, with or without internet present.
- AuthenticateCaller and provider verify each other with OfflineID and open an MLS-encrypted session along the route. No CA lookup, no round-trip to a server.
- InvokeThe request crosses three hops, the response comes back the same way, each leg acknowledged and retried. A device five hops away is invocable like an endpoint.
Illustration: what the console sees when it discovers thermal-cam.v1. Two providers answer, unit-19 at three hops and unit-23 at five. unit-19 is chosen, both OfflineID keys verify and an MLS session opens, and a capture request returns 200 OK in 240 milliseconds.
Hover a step to see it in the console.Advertise: every provider that heard the announcement answers with its version, capabilities, and hop distance.Discover: the console chooses before it sends anything. Closest wins unless a farther one has what you need.Authenticate: Ed25519 keys on both ends, checked locally. The session is encrypted end to end.Invoke: request and response are matched by id, so many calls can be in flight at once.
Beyond one WiFi segment
Developers looking for local discovery usually land on mDNS, Bonjour, or DNS-SD. Those answer a narrower question.
The result behaves like an API layer for physical space with no server behind it. It is the invocation layer of the platform, above 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
Anything a device can answer for becomes a service. These are the kinds of capabilities devices publish on the mesh, and the list grows with every app that registers one.
air-quality.v2gps-fix.v2thermal-cam.v1tank-level.v1vibration.v1inference.v1translate.v1ocr.v1compute.v1route-plan.v1map-tiles.v1firmware.v1briefing.v1media-drop.v1task-board.v1roster.v1relay-uplink.v1time-sync.v1print.v1shelter-status.v1medical-supply.v1sos.v1headcount.v1venue-poll.v3schedule.v1local-chat.v1pos-sync.v1your-service.v1Register a service →Under the hood
The mechanics beneath the API, each verified against the SDK.
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.
Where it applies
- Constrained devices
- Agent-to-agent invocation with no broker in the middle.
- Autonomous vehicles
- Capability sharing between vehicles across the fleet.
- Industrial sites
- 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 request carries the caller's address and is signed with its Ed25519 identity key, so a provider sees exactly who is calling and decides per identity whether to answer. Keep confidential content in MLS-encrypted messages between the same peers.
Is this in production or a research protocol?
It ships in the SDK today, and it runs on the same mesh network that has reached 350,000+ devices across 140+ countries, with 11,500+ local networks active this month. Those figures are the network's reach, not a count of devices calling services.
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, up to 10 hops by default.
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 on iOS and Android, and the same calls are in the Python binding and the Rust crates.
