Service discovery without a server
TL;DR
Offline Protocol Service Discovery lets a device advertise a named capability that peers find over the multi-hop mesh, authenticate with OfflineID and invoke over MLS. There is no DNS or registry server, and unlike mDNS or Bonjour it does not stop at the subnet boundary.
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, and when that something is unreachable, discovery fails before your request ever leaves the device.
Service Discovery, the coordination layer of Offline Protocol, inverts the model. A device announces what it can do, and nearby devices learn about it directly. There is no registry server to keep alive, because the announcement itself, carried by the devices, is the registry.
Serverless service discovery on the mesh
Service discovery on the mesh takes four steps: advertise, discover, authenticate, and invoke.
Advertise. Any device publishes a named capability with a request/response contract: an ID, a version, and key-value capability metadata, for example the languages a translation service supports or the format a sensor emits. The registration lives in the mesh.
Discover. Peers up to 10 hops away learn of the capability through the same multi-hop routing that carries regular messages on the DORS mesh. A consumer broadcasts a discovery query, for one service ID or for everything in range, and each responding provider announces its peer ID, version, capabilities, and how many hops away it sits. Discovery works identically with or without internet present.
Authenticate. Caller and provider verify each other with OfflineID, Ed25519 identities whose addresses derive from the key, and open an MLS-encrypted session. No CA lookup, no round-trip to a server.
Invoke. Request and response travel over the mesh with acknowledgment, retry, and deduplication. Requests are correlated by ID, so multiple invocations can be in flight at once. A device five hops away is invocable like an API endpoint.
Service discovery vs mDNS, Bonjour, and DNS-SD
Service Discovery is built for the case where there is no shared network at all. Developers searching for local 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 you found.
Announcements travel over BLE and WiFi Direct links, 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.
Adding service discovery with the TypeScript SDK
Service Discovery ships in the same TypeScript SDK as transport and identity, running on a Rust core on iOS and Android. The SDK surface is the one every developer already knows from HTTP clients. Here is what starting a node and sending over the mesh looks like:
// npm install @offline-protocol/mesh-sdk
import { OfflineProtocol, MessagePriority } from '@offline-protocol/mesh-sdk';
const protocol = new OfflineProtocol({ appId: 'my-app', profile: 'user123' });
protocol.on('message_received', (event) =>
console.log(`From ${event.sender}: ${event.content}`));
await protocol.start();
await protocol.sendMessage({
recipient: 'user456',
content: 'Hello!',
priority: MessagePriority.High,
});
Registering a capability and invoking one work through the same protocol object, with encryption, retry, and multi-hop routing as the default path rather than extra code you write.
Mesh service discovery use cases
The pattern shows up wherever devices need to coordinate without a broker. A device with a loaded model registers an inference service and nearby devices send it requests without cloud access. Sensors register as data providers and get queried in real time. Devices that have cached maps or firmware updates serve them to the nearest peer. At a venue, live polling, file drops, and local chat rooms register as services on the crowd’s own mesh, no app server required.
It runs on the same network that has reached 350,000+ devices across 140+ countries. The deeper walkthrough is on the service discovery page, and if you want to scope it against a real system, talk to us.
Frequently asked questions
What does a service advertisement contain in Offline Protocol?
A named capability with a request/response contract, made of an ID, a version, and key-value capability metadata, for example the languages a translation service supports or the format a sensor emits.
Does mesh service discovery need an internet connection?
No. Discovery works identically with or without internet present, and caller and provider authenticate with OfflineID with no CA lookup and no round-trip to a server.
Can several service requests be in flight at once?
Yes. Requests are correlated by ID, so multiple invocations can be in flight at once, and request and response travel over the mesh with acknowledgment, retry, and deduplication.
Why not use mDNS or Bonjour for local service discovery?
Those protocols answer what is on this WiFi segment right now. They stop at the subnet boundary, assume everyone shares an access point, and say nothing about calling the service you found.
What can devices offer each other through mesh service discovery?
A device with a loaded model can register an inference service that nearby devices call without cloud access, sensors can register as data providers, and devices with cached maps or firmware updates can serve them to the nearest peer.
Which platforms does Offline Protocol Service Discovery run on?
It ships in the same TypeScript SDK as transport and identity, running on a Rust core on iOS and Android.