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, its architecture and transport 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
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 and commercial integration route.Install the Rust crates
Use Rust 1.87 or newer. For a full peer: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.