Can Offline Protocol run on a Raspberry Pi?

A Raspberry Pi runs Offline Protocol as an ordinary Linux aarch64 host. The packages that cover it, as of 0.31.0 (October 2026):

Python is the one to start with. It is the binding that ships transport bridges for a host (Bluetooth LE, LAN peer streams, an internet relay client and a gateway client), so a Pi gets a working peer from one install. Java and C give you the engine, and your process does all the I/O. How do I use Offline Protocol from Python? covers the API.

pip install offline-protocol-sdk

The Linux wheels need glibc 2.34 or later on a 64-bit Arm system, and the SDK’s Python docs say glibc 2.34 means Debian 12, Ubuntu 22.04, RHEL 9 or newer. The Raspberry Pi documentation says the latest Raspberry Pi OS is based on Debian Trixie and the previous version on Debian Bookworm; Debian lists those as versions 13 and 12. Both meet the floor.

Two things decide whether pip finds a wheel:

• 64-bit, not 32-bit. Raspberry Pi OS comes in 64-bit and 32-bit versions, and the Raspberry Pi documentation names the Raspberry Pi 3, 4 and 5 among the models with 64-bit processors. The SDK publishes a wheel for aarch64 only, so a 32-bit install has no wheel.
• glibc 2.34 or newer. An older release has no wheel either. On any other distribution, check that its glibc is 2.34 or newer.

The package has no source distribution, so on a host without a wheel pip reports no matching distribution. Build from source there: the Python README’s build-desktop.sh compiles the Rust core for the host and generates the bindings.

Bluetooth LE on a Raspberry Pi runs in both roles: the central through bleak and the peripheral through bless, both over BlueZ. The SDK starts the peripheral when ble_enabled is on, and from 0.29.0 the peripheral serves the optional Hello characteristic and binds each central to the address its hello proves, so a phone can start an encrypted session with the host. The docs record it running between an Android phone and Macs and Raspberry Pis.

Several BlueZ behaviours were found on Raspberry Pi 4s, and the SDK’s Python bridge contract records how it handles them:

• No service filter on scans. On a Raspberry Pi 4 running BlueZ 5.87, bluetoothd exited as soon as a discovery filter naming a service UUID was set. On Linux the central now scans unfiltered and drops advertisements without the mesh service UUID itself.
• Both roles follow bluetoothd. When bluetoothd restarts, everything registered with it is gone. The SDK watches for the restart and registers the scanner, the GATT application and the advertisement again, retrying for about fifteen seconds.
• A wedged controller is reset once. On two Raspberry Pi 4s (Linux 6.18, BlueZ 5.87) the kernel lost track of the controller’s advertising, and every new advertisement was refused. The peripheral now powers the adapter off and on once through BlueZ to clear it. That reset drops every link the adapter holds, for every process using it.

Another process advertising on the same adapter may hold its only advertising slot. Qualify radio support and permissions on your own board, as the docs ask.

A Raspberry Pi can run one engine for several programs with offline-protocol-service, which the Python package installs. Applications talk to it over JSON-RPC 2.0 on a WebSocket, through a Unix socket by default, and share one identity, one set of peers and one document store. On a headless Pi with no secret service, the service runs on the built-in file stores under a store key:

export OFFLINE_PROTOCOL_STORE_KEY="$(openssl rand -hex 32)"   # once; keep it
offline-protocol-service --config config.json \
    --mls-root /var/lib/example/keys --state-root /var/lib/example/state \
    --socket /run/example/api.sock --listen 0.0.0.0:7878 --peer 10.0.0.2:7878

From 0.29.0 the service starts every transport the configuration enables. With ble_enabled it starts both Bluetooth LE roles so phones can find the host, and --lan, with the lan extra, finds other hosts on the network over DNS-SD with no --peer list. offline-protocol-verify drives the running service and waits for the events that prove a message was held, carried and delivered.

A Raspberry Pi suits the gateway role the Python docs are written for: a fixed host on a site that phones and other hosts reach locally. The Python README names “a gateway, a site computer” as the host that runs the service with both extras:

pip install 'offline-protocol-sdk[lan,http]'

In that role the Pi can:

• Meet phones on the same Wi-Fi. An iPhone on 0.28.0 or later, and an Android phone on 0.29.0 or later, find a Python host on the same Wi-Fi network over peer streams, when the network allows multicast. Android Wi-Fi Direct groups do not include the host.
• Meet phones over Bluetooth LE through BlueZ, as above.
• Carry calls for programs without the SDK. The http extra adds the HTTP front, so a program on the Pi can call a service on another device with a plain HTTP request.
• Reach the internet when it has a link. The relay client connects to a provisioned relay; set an auth token, because the docs warn that without one the manager falls back to the profile string, which is forgeable.

The reticulum slot is a different kind of gateway: a client for a separately deployed gateway daemon. The Python package ships the device half of the gateway-daemon contract, and the daemon is deployed separately. What is a gateway in a mesh network? explains the general role.

A Raspberry Pi Pico is a microcontroller board, not a Linux computer, so it runs firmware rather than the Python package. The Raspberry Pi documentation says the original Pico uses the RP2040 with Cortex-M0+ cores, and the SDK’s Rust crate offline-protocol-leaf builds for thumbv6m-none-eabi, the target its table lists for Cortex-M0 and M0+ with the RP2040 as the example. The leaf makes a device an encrypted member of a group that a full peer, such as a Raspberry Pi running Python, sets up. Offline Protocol also runs on ESP32 hardware today: the IntelligenceMesh Relay relays encrypted mesh traffic over Bluetooth LE. Which microcontrollers can run Offline Protocol? covers both.