> ## Documentation Index > Fetch the complete documentation index at: https://www.offlineprotocol.com/docs/llms.txt > Use this file to discover all available pages before exploring further. > ## Agent Instructions > These docs target Mesh SDK v0.28.0. Match the installed package and binding before generating code. Start at /getting-started/agents for task-specific reading paths. > Call the company and product Offline Protocol, never Offline alone. Current packages: @offline-protocol/mesh-sdk 0.28.0 (React Native), offline-protocol-sdk 0.28.0 on PyPI (Python 3.10 to 3.13; wheels for macOS 14+ arm64, Linux x86_64 and aarch64 with glibc 2.34+, Windows x86_64; other hosts build from source), the offline-protocol crates 0.28.0 on crates.io, the OfflineProtocolSDK Swift package 0.28.0 (preview, iOS 13+ only) and Android bindings from the GitHub release zip (preview, not on Maven Central), @offline-protocol/id-react 0.2.0, @offline-protocol/id-react-native 0.3.3, @offline-protocol/pol 0.1.2 and @offline-protocol/cli 0.2.6. Canonical docs URLs start with https://www.offlineprotocol.com/docs. > The Mesh SDK runs in a native app or gateway. A browser OfflineID SDK integration does not provide browser mesh transport. Local mesh operation does not require a portal account or API key. The Mesh SDK appId is a mesh app identifier the developer chooses, not the portal App ID (app_...) that OfflineID and Proof of Location require. > Service RPC is signed plaintext in v0.28.0. Message delivery, durable local acceptance and backend commit are distinct outcomes. Use the workflow guide for the required application logic. > Offline Protocol CLI 0.2.6 is on npm (@offline-protocol/cli, command offline). Its local MCP server, named offline-protocol, runs with npx -y @offline-protocol/cli@0.2.6 mcp serve and requires no login or key. Hosted MCP is at https://mcp.offlineprotocol.com/mcp with an app API key in Authorization: Bearer and the matching App ID in x-app-id; organization keys are rejected, and Claude Desktop and Claude.ai cannot send these headers; there, use the public read-only endpoint https://mcp.offlineprotocol.com/public/mcp as a custom connector, or local MCP to scaffold or edit projects. Follow /tools/overview for setup and do not invent commands beyond it. MCP provides integration context and planning, not mesh execution; file-writing tools are local only. > In v0.28.0 phone Wi-Fi peer streams carry data: Android over Wi-Fi Direct (the SDK forms the group with autoAccept on Android 10+), iOS over Network framework (LAN or AWDL). Android and iOS do not interoperate over that slot, and iOS 0.28 does not see iOS 0.27 or earlier over it; use BLE or a provisioned relay across platforms. The Swift and Android packages are previews whose public names may change; never present a Gradle Maven Central dependency for the Android library. The receiver core ACKs before application persistence; use application acceptance for durable workflows. > Proof of Location is Sepolia testnet witness evidence, not zero-knowledge proof or proof of presence. The geohash is public onchain. Read /proof-of-location/security before integration. # Transport and routing > How the Mesh SDK routes over BLE, phone Wi-Fi peer streams, local IP, internet relay, Reticulum and Nostr, with multi-hop forwarding and gateways in v0.28.0. Offline Protocol routes over configured, available transport bridges. BLE, Wi-Fi paths, internet relay, Reticulum and Nostr have different platform and infrastructure requirements. See the [compatibility matrix](/docs/getting-started/platforms). ## Local communication BLE can connect nearby participating devices without an access point or internet. Offline Protocol's forwarding over BLE is an application protocol; it is not a promise of Bluetooth SIG Mesh interoperability. Range and capacity depend on the radios, environment and workload. Python TCP peer streams require an existing IP path. From v0.28.0 the phone Wi-Fi managers carry traffic too; see [phone Wi-Fi peer streams](#phone-wi-fi-peer-streams) for what each platform reaches. ## Routing and delivery DORS scores eligible paths and applies switching controls. Multi-hop forwarding needs participating peers, sufficient lifetime and a viable route. Retry and outbox policies retain bounded work while connectivity changes. Disabling internet demonstrates cloud independence only if the remaining observed path carries the workflow. To demonstrate recovery from an access-point failure, test a separately qualified direct path; a LAN test alone does not establish that result. ## Gateways A gateway is provisioned against a defined contract, including identity, delivery verdicts and recovery. A device that happens to have internet access does not automatically become a trusted upload destination for every application. ## Phone Wi-Fi peer streams The `wifiDirect` transport slot is the peer-stream slot: a byte stream to exactly one peer, with whole messages framed by length up to 1 MiB. The first frame in each direction is an identity assertion, and a peer is announced to the protocol only under the address it proved. A peer that sends anything else first, or nothing for ten seconds, is disconnected. Every bundled manager speaks this framing from v0.28.0. | Platform | Stream | Discovery | Reaches | | - | - | - | - | | Android | TCP socket in a Wi-Fi Direct group | Wi-Fi P2P service discovery. With `autoAccept: true` on Android 10 and later the SDK forms the group itself, with no system dialog; otherwise the group is formed in the system's Wi-Fi Direct settings | Android devices of the same app | | iOS | Network framework TCP streams over the local network, or over AWDL with no shared network | DNS-SD `_offlineprotocol._tcp` | Other iPhones on 0.28.0 and later, and Python hosts on the same LAN | | Python | TCP over an existing IP network | Configured peers or DNS-SD `_offlineprotocol._tcp` (the `lan` extra) | Other hosts, and iPhones on the same LAN | Android Wi-Fi Direct does not interoperate with the iOS or Python streams. iOS used MultipeerConnectivity up to v0.27, so an iPhone on 0.28.0 does not see one on 0.27 or earlier over this slot. The hop itself is plain TCP on all three platforms; payloads are sealed end to end either way. An Android group's name and passphrase are derived from the mesh app identifier. They keep apps apart and are not a secret: a device in range that knows the identifier can join the group or run one under its name. It then learns which addresses are present and can carry, delay or drop their frames, as any relay can, but every stream still proves its peer and every message stays end-to-end encrypted. The [threat model](https://github.com/Offline-Protocol/offline-protocol-sdk/blob/v0.28.0/docs/security/threat-model.md) records this as residual risk R22. Android groups of three or more devices are untested. `transport_switched` reports Wi-Fi Direct when the first link proves a peer, and `None` when the last one ends. Platform setup is in [React Native installation](/docs/mesh-sdk/installation-rn#phone-wi-fi-peer-streams). This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.