Advertise and invoke a capability with no server
Last updated
Turn a device into an API endpoint on the mesh. This guide walks through advertising a capability, discovering it from another device, and invoking it request/response, all with no server, no DNS, and no registry.
A provider that advertises a named capability, and a consumer that discovers it up to 8 hops away, authenticates with OfflineID, and invokes it request/response over an MLS-encrypted session, with no server and no infrastructure.
Why serverless 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. Developers searching for local discovery usually land on mDNS or Bonjour, but those stop at the subnet boundary and say nothing about calling what they found.
Service Discovery inverts the model. A device announces what it can do, and nearby devices learn about it directly, with the announcement propagating hop by hop across the DORS mesh. Discovery and invocation are one primitive: finding a service and calling it use the same authenticated, encrypted session machinery. It behaves like a serverless API layer for physical space. See how it works for the full picture.
Prerequisites
- The SDK installed, initialized, and joined to the mesh, from the quickstart.
- A capability you want to expose, defined as a request/response contract with an ID, a version, and any capability metadata.
- Two or more physical devices, one advertising the service and one discovering it.
Steps
The provider publishes a named capability with a version and key-value capability metadata, for example the languages a translation service supports or the format a sensor emits. There is no registration server; the announcement lives in the mesh itself.
A consumer broadcasts a discovery query, for one service ID or for everything in range. The query propagates hop by hop through the mesh, so a provider up to 8 hops away, with no direct radio contact, is still discoverable. Each responder reports its version, capabilities, and hop distance.
Caller and provider verify each other with OfflineID (Ed25519, trust-on-first-use) and open an MLS-encrypted session. Providers decide per identity who may call. There is no CA lookup and no round-trip to a server.
The consumer sends a request and gets a response back over the mesh, with acknowledgment, retry, and deduplication inherited from the transport. Requests and responses are correlated by ID, so many invocations can be in flight at once. A device five hops away is callable like an API endpoint.
The exact calls to register a service, run a discovery query, and invoke a provider are in the API reference. Follow the documentation for signatures rather than guessing at method names.
What you get
A capability that any device on the mesh can find and call, authenticated per identity and encrypted end to end, with the reliability guarantees an API client expects. It is the coordination substrate for local AI inference, sensor feeds, content delivery, and field coordination, the same programming model developers know from HTTP clients, running on a network that does not need the internet to exist.
Next steps
Service discovery FAQ
How is this different from mDNS or Bonjour?
mDNS discovers names on a single local network segment and stops at the subnet boundary, and it says nothing about calling the service it found. Service Discovery propagates announcements across multiple hops and multiple transports, and pairs discovery with authenticated request/response invocation in one primitive.
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 8 hops.
Can a capability be restricted to specific callers?
Yes. Every invocation is OfflineID-authenticated, so providers decide per identity who may call, and sessions are MLS-encrypted end to end.
Is there a registry server to keep running?
No. There is no registry server. Each device announces its capabilities to nearby peers, those announcements propagate hop by hop, and the announcement itself, carried by the devices, is the registry.
