Peer-to-peer mesh networking

Through bridges. A device that can see two clusters connects to both, so separate pockets of devices merge into one routable network.

Member role

Connections inside a cluster of nearby peers carry traffic within the group.

Bridge role

Connections that link two separate clusters. Bridges stitch isolated pockets of devices into one routable network.

Connection budget

Each device holds about four peers, scoring every candidate on RSSI, free slots, uptime, battery, stability, and load.

Self-rebalancing

The budget rebalances roughly every 15 seconds, and candidates that would bridge clusters get a scoring bonus, so the mesh actively unifies itself.

Battery-aware relay

Well-charged devices take on relay duty and devices low on energy shed it, so the mesh balances its own load across the fleet.

Gradient routing

A message forwards toward the few best paths at once, not one pre-computed route, so a link that drops mid-flight never strands it.

Exactly-once delivery

An 8-hop TTL, acknowledgment, retry, and deduplication give a message many ways to arrive and exactly one delivery when it does.

Yes. iOS and Android phones running the SDK link over Bluetooth LE and a direct Wi-Fi peer link, with no extra hardware.

No special hardware

The phones people already carry ship with Bluetooth LE and Wi-Fi radios, WiFi Direct on Android and peer-to-peer Wi-Fi on iPhone, and the SDK turns those radios into mesh links.

Bluetooth LE

Handles peer discovery and small messages at very low power.

WiFi Direct

Carries bulk data, including chunked file transfer up to 100 MiB, when both ends support it. On Android 10 and later the SDK can form the group itself, with no system dialog. iPhones have no WiFi Direct, so between iPhones the same transport runs over the Network framework, on the local network or AWDL. Since SDK 0.29, an Android phone also finds iPhones and Python hosts on the Wi-Fi network it is on, with no group.

Coverage is the fleet

Every device that installs an app built on the platform becomes a relay, so density in a stadium, warehouse, or staging area translates directly into throughput and reach. In production that is 350,000+ devices reached in 140+ countries and 11,500+ local networks active this month, grown on product pull alone.

No base station

Nothing to deploy and no gateway to keep powered. The network is the devices.

One npm install

A TypeScript API in the React Native SDK over a Rust core, with encryption, retry, and multi-hop routing as the default path.

The recipient acknowledges every message, and the sender retries with backoff until the acknowledgment arrives or the retry budget runs out.

Confirmed, not fire and forget

A message is done when an acknowledgment comes back from the recipient and message_delivered fires with latency and hop count. The ACK timeout is about 10 seconds, with up to 1,000 acknowledgments tracked in flight.

Backoff that respects the link

Retries start at 1 second and double to a cap of 5 minutes, for up to 10 attempts, so a flapping peer is retried quickly at first and then patiently.

An outbox with a memory

A message lives in the persisted outbox for up to 7 days. A peer that walks back into range within that window still gets the message it missed.

Parked, then re-driven

A message with no path is parked rather than failed: probed on every carrier with a backoff from 15 seconds to 10 minutes, and re-driven the moment a peer reappears or a link returns.

Safe to relay

Each device deduplicates by message id, about 5,000 recent ids kept for 7 days across restarts, and every message carries an 8-hop TTL, so multi-hop forwarding processes a message once and cannot loop the mesh.

Encrypted by default

Sessions use MLS (RFC 9420) with Ed25519 identities. Relay nodes forward ciphertext, and keys never leave the device.

A clean contract

Your application sees sent, then delivered or failed, with the reason and the retry count attached when the budget is exhausted. Every setting above is tunable through ReliabilityConfig.

Yes. A file of up to 100 MiB moves device to device in acknowledged chunks, encrypted with MLS like a message.

One call to send

sendFile takes a recipient, the file's bytes, and a name, and returns a file id. sendFileFromPath takes a path instead, and the Rust core reads the file itself, so a large file never crosses the React Native bridge as base64. The file moves device to device with no upload endpoint and no intermediary host.

Chunked by default

Files are split into chunks sized for the carrier and reassembled on arrival: 4 KiB over Bluetooth LE, 32 KiB over the Wi-Fi peer link and 256 KiB over the internet. The engine's limit is 100 MiB per file, and in 0.31.0 it cannot be changed through the SDK interface; sendFileFromPath refuses a larger file before reading it.

Survives a dropped link

Each chunk is tracked and acknowledged on its own, so a link that drops mid-transfer redelivers only the chunks in flight. A transfer stays on the carrier it started on for every chunk and every retry.

Progress and control

A file_progress event reports the percentage complete, getFileProgress reads status by id, cancelFileTransfer stops a transfer, and file_received fires on the recipient when the last chunk lands.

Encrypted like a message

Chunks travel with the protocol's default MLS end-to-end encryption, so a large payload is protected on the wire the same way a short message is.

Wherever people, machines and devices on one site have to keep handing work to each other: robot fleets, emergency response, industrial crews, and apps that call services on nearby devices.

Robotics and autonomy

Swarm coordination across fleets when links and GPS drop.

Public sector

Disaster-resilient communication through outages and shutdowns.

Industrial sites

Crews, equipment, and gateways keep coordinating off-grid, with the mesh moving with the work.

Above the transport

Service discovery turns the mesh into an invocable network of capabilities.