> ## 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.27.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.27.0 (React Native), @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 API key.
> Service RPC is signed plaintext in v0.27.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 runs with offline mcp serve and requires no login or key. Hosted MCP is at https://mcp.offlineprotocol.com/mcp with an application API key in Authorization: Bearer and a matching x-app-id; organization keys are rejected. 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.
> Phone Wi-Fi Direct and MultipeerConnectivity carry no data in v0.27.0. Use BLE or a provisioned relay. 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.

# Rust and constrained devices

> Integrate Offline Protocol in Rust: a full protocol peer or the constrained offline-protocol-leaf firmware component, with your transport and storage.

## Full peer

The Rust crates implement protocol state, routing, reliability, MLS and service discovery. Platform code supplies transport I/O and persistent storage. Use a full peer when the device must manage sessions, route traffic or host the complete coordination stack.

Start from the [versioned SDK workspace](https://github.com/Offline-Protocol/offline-protocol-sdk/tree/v0.27.0), its [architecture](https://github.com/Offline-Protocol/offline-protocol-sdk/blob/v0.27.0/docs/architecture.md) and [transport bridges](https://github.com/Offline-Protocol/offline-protocol-sdk/tree/v0.27.0/docs/bridges).

## Constrained leaf

`offline-protocol-leaf` is a firmware component for a constrained device. It processes protocol frames and participates in MLS as a member that never issues commits. A full peer creates the group and performs membership commits; the leaf joins, receives, responds and persists its state.

Two leaves cannot establish a session with each other on their own. Pair the device with a phone, Linux host or another full peer over a compatible radio path.

## Firmware responsibilities

| Requirement | Integration responsibility |
| - | - |
| Radio I/O | Receive and send protocol frames over the device's selected link. |
| Entropy | Connect cryptographic randomness to a suitable hardware source. |
| Time | Supply time at pairing for key-package validity checks. |
| Durable storage | Implement atomic persistence; protect cryptographic state across power loss. |
| Authorization | Decide which enrolled peers may read data or operate the device. |

The MCU does not inherit the phone or Python relay client. For internet transport, implement a firmware client with connection, authentication and address proof, or use a companion full peer that already has the client. An existing direct upload from the MCU to its own backend can remain unchanged.

## Qualify the target

Measure flash, RAM, latency, power, storage endurance and restart behaviour on the selected part and radio stack. Define the full-peer/leaf topology before quoting device capacity or transport support.

See the [leaf source and contract](https://github.com/Offline-Protocol/offline-protocol-sdk/tree/v0.27.0/crates/offline-protocol-leaf) and [commercial integration route](/docs/operations/licensing).

## Install the Rust crates

Use Rust 1.87 or newer. For a full peer:

```bash theme={null}
cargo add offline-protocol@=0.27.0
```

For a constrained device:

```bash theme={null}
cargo add offline-protocol-leaf@=0.27.0 --no-default-features --features bare-metal-rng
```

Do not combine `bare-metal-rng` with the default `std` feature. Register `getrandom::register_custom_getrandom!` with the device's hardware entropy source; enabling the feature alone does not supply randomness. A missing or predictable entropy implementation makes key generation unusable or unsafe. The leaf API centers on `LeafDevice` and `LeafStore`; a leaf requires a compatible full peer for session establishment. Two leaves cannot establish that session with each other.