Open sourcing the coordination layer for the disconnected edge
A year ago, Offline Protocol was a thesis: the next generation of software would need to keep working without the internet.
Today, that thesis runs across more than 350,000 devices in over 80 countries and more than 10,000 active mesh clusters. It powers consumer applications, developer tools, and hardware experiments. It has been tested through unreliable radios, interrupted sessions, changing routes, mobile operating-system constraints, and the ordinary messiness of real-world use.
Now, we are open sourcing the infrastructure behind it.
The internet should not be a prerequisite
We call software global, then design it for perfect connectivity.
Authentication calls a server. Discovery calls a server. Data exchange calls a server. Coordination calls a server. Two devices can be physically beside one another and still become functionally unreachable when the path to distant infrastructure disappears.
That topology becomes even more limiting as software moves beyond screens. Agents, robots, drones, vehicles, sensors, and on-device models will need to discover, verify, and coordinate with the machines around them. Routing every local interaction through the cloud introduces latency and a shared point of failure into systems that increasingly operate in the physical world.
The usual response is an offline mode. Cache a screen. Queue a request. Show a better error message. Wait for the network to return. Those choices can improve the experience, but they do not make the underlying system resilient. A product that must wait for reconnection before it can discover, verify, exchange, or coordinate is still built around the assumption that the internet will come back soon.
That assumption fails in more places than the technology industry likes to admit. Connectivity becomes unavailable during disasters and deliberate shutdowns. It becomes unreliable across rural routes, remote operations, crowded events, industrial sites, and developing infrastructure. It becomes expensive across satellite backhaul and constrained mobile networks. Even in the most connected cities, it disappears underground, inside buildings, and at the exact moment demand overwhelms capacity.
These are not isolated edge cases. They are the operating conditions of a large part of the world.
Offline Protocol exists to make connectivity a capability rather than a prerequisite.
From applications to infrastructure
We did not begin by trying to design a universal platform on paper. We built products.
Fernweh and MINE put the network into people’s hands. Our hardware relay infrastructure experiments tested what happens when the same coordination layer moves beyond phones. Each product exposed a different part of the problem: discovering nearby devices, maintaining identity across changing paths, delivering information reliably, recovering from interruption, operating within battery limits, and making all of it usable by people who should never need to understand the network underneath them.
Those lessons became the Offline Protocol Mesh SDK.
At its core is a modular Rust protocol engine for applications and devices that need to continue operating when connectivity is unavailable, degraded, expensive, saturated, or deliberately disrupted. Around it are the pieces required to make that engine useful in real systems: multi-transport routing, peer discovery, multi-hop delivery, encrypted communication, acknowledgments and retries, file transfer, service discovery, and opt-in observability. These are also the foundations a growing population of intelligent devices will require: a peer layer for identity, privacy, transport, trust, and coordination that does not disappear when a cloud route does.
The same core now reaches React Native applications on iOS and Android and Python environments on macOS, Linux, and Windows. Release artifacts are available for mobile and desktop integration, and developers working directly in Rust can build transport bridges for their own operating systems, radios, and hardware. The SDK has already crossed 9,000 downloads this year. More importantly, it has matured beyond one application, one framework, or one network path. It is becoming the shared coordination layer we set out to build.
Why we are opening it
Infrastructure for the disconnected edge should be open for the same reason the internet’s foundational protocols are open: the people depending on it should be able to inspect it, test it, adapt it, and improve it.
No single company can anticipate every environment where connectivity fails.
A logistics team understands the dead zones across its routes. A disaster-response organization understands what remains after local infrastructure goes down. A robotics team understands which decisions cannot wait for the cloud. A wallet developer understands which actions can be signed and exchanged locally and which still require access to the relevant network. A remote operator understands what belongs on nearby links and what is important enough to consume constrained backhaul.
Opening the SDK lets those builders bring their real requirements into the infrastructure instead of rebuilding the same foundations independently. It also makes our claims inspectable. Developers can examine how messages move, how retries behave, how routes are selected, how cryptographic state is handled, where application responsibility begins, and what the system does when a path fails. They can test it under their own failure conditions rather than accepting a polished demonstration as proof. That matters because resilience is not a feature that can be established by marketing language. It is behavior under failure, measured in the environment where a system is expected to survive.
What this makes possible
The SDK is not only for messaging applications.
It is for mobile products that need nearby discovery, offline authentication, or secure local exchange. It is for fleets and field systems that must retain and deliver information through coverage gaps. It is for remote telemetry, industrial devices, robots, wallets, and connected hardware that cannot route every interaction through the cloud. It is for local service networks where devices can advertise and invoke capabilities without depending on DNS or a central registry for discovery. It is also for systems we have not imagined.
One of the most important capabilities in the SDK is service discovery. A device can advertise what it can do, other devices can discover that capability through the local mesh, and an application can invoke it through a request and response pattern. A sensor, local model, control function, file, or application workflow can become available to the devices around it without first being placed behind a distant server. That changes the role of the mesh. It is no longer only a path for carrying messages. It becomes a local service network whose infrastructure is formed by the devices participating in it.
As intelligence moves onto phones, vehicles, robots, and field hardware, coordination has to follow. Those machines will discover services, exchange data, request capabilities, and initiate signed actions at a scale the current device-to-cloud model was not designed to support. Some interactions can happen locally. Others, including final blockchain broadcast or settlement, still require the relevant external network. A resilient peer layer lets applications make that distinction instead of forcing every action through an immediate cloud round trip.
Across the wider Offline Protocol stack, OfflineID provides portable identity, the Mesh SDK provides multi-transport communication and coordination, MLS protects encrypted sessions, and service discovery exposes capabilities available nearby. Together, these primitives point toward infrastructure for both the disconnected systems of today and the emerging machine economy.
Opening the next stage of Offline Protocol
Open sourcing the Mesh SDK is not the finish line.
Our immediate focus is making every supported path easier to adopt: clearer installation, stronger examples, safer upgrades, better diagnostics, expanded compatibility testing, and documentation that lets developers evaluate the SDK without needing the core team in the room. We will soon launch an evolved developer platform for seamless adoption.
For companies looking to build with us, we are opening scoped design-partner evaluations for teams building mobile applications, wallets, logistics systems, remote telemetry, industrial devices, DePIN hardware, and bandwidth-constrained infrastructure. These engagements begin with one real workflow, a defined connectivity failure, and measurable success criteria. If the SDK does not create value under those conditions, the evaluation should end there. If it does, there is a credible foundation for adoption.
The SDK will also underpin our CLI and MCP developer tooling as that platform develops. The objective is to make disconnected-edge capabilities accessible not only inside applications, but through the workflows developers and agents already use to discover, test, and integrate infrastructure.
Most importantly, the repository is now an invitation. Build with it. Break it. Inspect the assumptions. Bring us the environments we did not anticipate and the failure conditions a simulator cannot reproduce. Show us what devices need to do before the connection returns. The internet remains the most capable network humanity has built. Our goal is not to replace it. Our goal is to stop treating it as a prerequisite for every interaction between nearby people, applications, and devices.
Get started
Explore the SDK and contribute on GitHub, read the documentation, or install the React Native package:
npm install @offline-protocol/mesh-sdkThe Offline Protocol Mesh SDK is available under AGPL-3.0-only for projects that comply with its source-disclosure obligations. Commercial licensing is available for proprietary products. Licensing, security, contribution, export, and trademark information is included in the repository.
Satvik is the founder and CEO of Offline Protocol. The through line in his work has always been building for the people default systems leave out: he founded Runaway, a youth mental health community recognized by Mental Health America, UNICEF, and the World Health Organization, and co-founded RELI3F, a humanitarian initiative that raised over $2 million for relief efforts in Ukraine.
Before Offline Protocol he was founder and CEO of Anokha (acquired) and Global Product Lead for NFTs at Mastercard. He angel invests and advises early-stage founders, has been featured in Forbes, TIME, Mashable, and Vice, and when he is not working is usually in a boxing gym or deep in a hardware project.
Gokul is the CTO of Offline Protocol. He came to the disconnected edge through more than half a decade across infrastructure protocols, distributed systems, and developer tooling, where systems that cannot rely on a central server force you to get the fundamentals right: state that syncs eventually, identity that proves itself locally, transport that finds a path.
Much of that philosophy took shape in his open-source work, mostly Rust developer tools like wrkflw, Snipt, and Feedr that have earned thousands of stars, and the same open, verifiable ethos runs through everything he ships. Off the keyboard he is usually rock climbing, on a motorcycle, or backpacking somewhere with no signal, which is probably not a coincidence.