Skip to main content

API Methods

Constructor

See Configuration for all config options.

Lifecycle Methods

Messaging

Connection Requests

Media & File Transfer

All media methods accept base64-encoded file data. The SDK handles chunking and reassembly automatically.

Transport Management

Bluetooth

Network Topology

Battery & Relay

DORS Configuration

Reliability Configuration

Gradient Routing

End-to-End Encryption (MLS)

MLS is automatically initialized when start() is called (if encryption.enabled is true). These methods provide manual control over encryption operations.

Session Management

Key Package Management

Low-Level Session Operations

Identity & Signing

Trust

Group Messaging

Groups use MLS for end-to-end encryption with mesh transport for delivery.
Example:

Presence, Typing & Read Receipts

User Blocking

Service Discovery & RPC (MeshServices)

Service Discovery turns the mesh into an offline internet — a network where every device can be both a client and a server. Devices register capabilities, others discover them through multi-hop routing, and invoke them with a request/response pattern. No server, no DNS, no infrastructure. On the traditional internet, you resolve a hostname, connect to a server, and make a request. Service Discovery follows the same pattern, but everything runs over the mesh. The devices around you are the infrastructure. While messaging moves data between known peers, Service Discovery lets devices find and interact with unknown peers based on what they can do.

How It Works

  1. A device registers a service with an ID, version, and capability metadata
  2. Other devices broadcast discovery queries that propagate across the mesh
  3. Providers respond with service_discovered events including their peer ID, version, and capabilities
  4. The consumer sends a request to a specific provider, which receives it as a service_request_received event
  5. The provider processes the request and sends a response back
Discovery queries propagate through the mesh via multi-hop routing, so services don’t need to be directly connected — a device 5 hops away can still be discovered and invoked, just like a server on the other side of the internet.

Setup

API

Provider Example

Consumer Example

Use Cases

Local AI Inference — A device with a loaded ML model registers an inference service. Nearby devices discover it and send classification or generation requests without needing cloud access. Sensor Data Feeds — IoT sensors register as data providers (temperature, air quality, GPS). Nearby devices discover and query them in real time, creating ad-hoc sensor networks with zero infrastructure. Decentralized Content Delivery — Devices that have cached content (maps, articles, firmware updates) register as content providers. Others discover and fetch what they need from the nearest available peer — a CDN that runs on the devices around you. Emergency Services — When infrastructure is down, devices register capabilities (medical supplies, shelter availability, communication relay). Rescue teams discover what’s available in their vicinity. The mesh becomes the network that disaster couldn’t take down. Collaborative Computing — Split a computation across multiple devices. One device registers a “compute” service, others discover it, send work units, and collect results — a mesh-native MapReduce. Event & Venue Services — Devices at a conference, stadium, or festival register services they offer (live polling, file drops, local chat rooms, schedule lookup). Attendees discover and use them without any centralized app server or internet connection.

Discovery Across the Mesh

Discovery queries are not limited to directly connected peers. They propagate through the mesh using the same multi-hop routing as regular messages. This means:
  • A service registered on a device 5 hops away can still be discovered
  • The hop_count field in service_discovered tells you how far away the provider is
  • You can use hop count to prefer closer providers for latency-sensitive operations
  • Multiple providers for the same service ID may respond — your app decides which to use

Event Listeners

You can also listen for all events with protocol.on('all', listener). See the Events Reference for all available event types and their payloads.

Next: Events Reference

See all event types and their payloads.