Offline Protocol browser binding
Offline Protocol runs in a web browser as a full mesh node through the SDK’s browser binding, experimental as of 0.31.0 (October 2026). The engine is the same Rust as every other binding, compiled to WebAssembly in the offline-protocol-web crate on crates.io, and the JavaScript in bindings/web runs it. You build the JavaScript from the SDK repository while its package is not yet published.
A browser is a full node. It mints its own identity, forms MLS sessions, creates and administers groups, and relays like any other node. The 0.31.0 release added the worker engine, durable nodes, WebRTC between devices, Nostr over the application’s relays, browsers on one network finding each other, group member removal, and Web Bluetooth links. Offline Protocol’s OfflineID packages for React are a separate product; mesh in the browser comes from this binding.
Engine worker and durable storage
The engine runs in a dedicated worker, because the only browser storage that is synchronous and can flush, an origin private file system (OPFS) sync access handle, exists only in dedicated workers. The engine writes key and ratchet state it depends on immediately, so an acknowledged write must already be on disk. A worker also keeps encryption work off the thread a page renders on.
Storage is a sealed append log per category in origin-private files:
- Every record is sealed with ChaCha20-Poly1305 and bound to its category, file generation and position, so a moved record does not authenticate.
- The 32-byte store key is sealed under a non-extractable AES-GCM key kept in IndexedDB. This protects the files at rest, and script on the same origin can drive the node.
- A Web Lock allows one node per account per origin. A second tab gets its own profile, or the page asks for
storage: "memory", which is a new device on every start.
The page needs a secure context, HTTPS or localhost, because OPFS, Web Locks and WebRTC exist only there. If the engine panics, the worker ends and the page restarts the node; a durable node comes back as the same device with every acknowledged write.
Browser links: tabs, WebRTC and Nostr
A browser node links to other devices four ways, all built on what a page is allowed to do:
| Link | What it reaches | What it needs |
|---|---|---|
BroadcastChannel | Other tabs of the same origin | Nothing |
| WebRTC data channel | A device on the same local network | Two connection codes carried by QR code or paste, or a room code through Nostr relays |
| Nearby room | Browsers behind the same network address | The application’s Nostr relays, a STUN server or a known network address, and an admit decision |
| Nostr transport | Any device by its address, including mobile ones, and usernames | The application’s Nostr relays |
WebRTC needs no server by default: each side’s code carries every candidate, so a connection forms on the local network or not at all. An application that must cross networks passes its own STUN and TURN servers. The SDK names no relay and no STUN server, so every relay a node uses is one the application chose. Nostr carries the setup and, on the Nostr transport, encrypted messages; the data on a WebRTC link runs over the local network.
The browser also has ephemeral sends, for state the next send replaces such as a game’s positions. An ephemeral message goes once over a live link, with no acknowledgement or retry. The native bindings do not expose it yet.
Web Bluetooth links to a phone or board
In Chromium, a page links to a phone or a board running the SDK as a Bluetooth LE peripheral, a feature added in 0.31.0. The engine carries the same Bluetooth LE transport and fragment codec every binding uses, so the page holds the GATT connection and moves bytes while the engine verifies identity and encrypts.
Web Bluetooth makes the page a GATT central, so the link starts from the page:
- The person picks the device in the browser’s chooser, from a click, or the page reconnects to a device the origin was granted before.
- The page reads the device’s identity, and the engine verifies that it proves the device’s address.
- The page subscribes to messages and writes a Hello, which tells the peripheral who is writing.
- The engine announces the link, and an MLS session forms over it.
The iOS, Android and Python peripherals serve the Hello, the iOS one from 0.31.0. The carrier writes fragments at the SDK’s 185-byte floor, the size every binding falls back to. CI drives the carrier through a stand-in for navigator.bluetooth whose devices are other engines playing the peripheral, and runs with Chrome on Android, macOS and Linux against an Android phone and a board follow a manual checklist.
Browser support: Chromium, Firefox and Safari
The binding lists Chromium, Firefox and Safari, and CI runs its test pages in Chromium, Firefox and WebKit through Playwright. WebKit there is Playwright’s build of Safari’s engine.
| Capability | Chromium | Firefox | Safari (WebKit) |
|---|---|---|---|
| Engine in a worker, tabs, WebRTC, Nostr, nearby rooms | Yes, tested in CI | Yes, tested in CI | Yes, tested in CI on WebKit |
| Storage conformance suites on real OPFS | Run in Chrome | Run in Firefox | Not run yet |
| Web Bluetooth | Yes | No | No |
Web Bluetooth is a Chromium feature: Firefox and Safari do not have it, and neither does any browser on iOS. Those browsers link over WebRTC and Nostr. Runs between two physical devices, including a phone’s browser and a tab the phone suspends, follow a manual checklist alongside CI.
Browser node scope
A browser reaches nearby devices the ways a page is allowed to: WebRTC on the local network, nearby rooms set up through relays, and Web Bluetooth in Chromium. Pages have no Bluetooth scanning, DNS-SD browsing or Wi-Fi Direct, so nearby rooms give browsers their local discovery. As of 0.31.0, a few parts of the native SDK are not in the browser build yet:
- Offline Protocol relay transport. Nostr reaches the same devices from a browser, by address or username.
- A project TURN server. The carrier takes the application’s own STUN and TURN servers for links across networks.
- Telemetry. The uploader needs a thread and a blocking client; a browser build will need a
fetchpath for it. - A published JavaScript package. Build from source, as below.
For a phone app with Bluetooth LE, Wi-Fi Direct and relays wired for you, React Native is the stable and most complete integration. The platforms overview compares every binding.
Building the browser binding from source
To build the module and its JavaScript glue from a checkout of the SDK, install the pinned wasm-bindgen command-line tool once and run the build script:
cargo install wasm-bindgen-cli --version 0.2.105 --locked # once
bash bindings/web/scripts/build.sh # module + glue in bindings/web/pkgA page then starts one worker per node through OfflineNode.start({ appId }), listens for the fatal event, and serves the engine module where the worker can fetch it. examples/web-two-tabs is the first page to open in two tabs, and examples/web-lobby is a two-player game between devices over WebRTC with durable nodes. The SDK is AGPL-3.0-only, with a commercial licence for proprietary use.