Sideband for LXMF messaging over Reticulum

Sideband's infrastructure-light LXMF role

Sideband addresses communication when relying on a central messaging account is unsuitable or impossible. It is an LXMF client, telemetry tracker, and remote-control client for Android, Linux, macOS, and Windows. The intended user is someone operating over Reticulum, including links based on LoRa, Packet Radio, WiFi, or I2P. The project also connects with other LXMF-compatible systems rather than requiring every participant to use the Sideband interface.

The application does not depend on an Internet server or a user account. The README describes it as anonymous and infrastructure-less, with LXMF providing peer-to-peer and distributed messaging. That changes the adoption decision. Sideband is not simply a conventional chat application with a radio transport added later. Its usability depends on Reticulum connectivity and the availability of peers, propagation nodes, routers, or compatible endpoints within the relevant network.

This is useful for field communications, amateur-radio systems, distributed deployments, and locations where ordinary Internet messaging is unavailable or undesirable. It is less suitable for a user who expects contacts to be globally reachable without configuring either network reachability or some form of propagation.

LXMF, LXST, and Reticulum data paths

Sideband's messaging path is built on LXMF over Reticulum. Reticulum provides the network substrate, while LXMF handles peer-to-peer and distributed message delivery. The README says Sideband works with other LXMF clients, including MeshChatX and Nomad Network. This compatibility means that the client is not the only required component on a network.

Voice calls use LXST. File and image transfers are also listed as supported functions. Audio messages are compressed with Codec2 and Opus, which the project identifies as enabling audio over bandwidth-constrained links such as LoRa. Exact audio performance is not documented, so its usability on a particular radio link cannot be inferred solely from the feature list.

Sideband can also exchange data through encrypted QR paper messages and links using the `lxm://` scheme. Offline maps support situation display, while geospatial calculations support location-related workflows. An Android device can act as a Reticulum Transport Instance, which the README describes as a way to set up or extend networks. These functions make Sideband broader than an LXMF inbox, although every additional subsystem also increases the configuration and trust decisions faced by the operator.

Telemetry and remote-control boundaries

The client includes direct telemetry and location sharing, remote telemetry queries, and a response engine for remote commands. The documented built-in commands include `ping`, `signal` reports, and `echo`. Plugins can add commands, services, and telemetry sources, so an installation's effective capabilities depend on loaded plugins as well as the application itself.

The README says telemetry querying uses authenticated and encrypted communication, but it does not publish a plugin trust model, sandbox policy, permission checklist, or command review procedure. Those omissions matter. Remote execution is useful for administering distributed systems, yet it is not the correct tool for an untrusted recipient or an unverified plugin source. An operator should determine who can issue queries, how plugins are selected, and how remote access is revoked before enabling either feature.

The system also presents location and situational-awareness data. The documentation states that no third party or server receives this data, but “no third-party server” should not be confused with “no exposure.” Screens, maps, local storage, plugins, device access, and remote-command authorization remain part of the user's security boundary. The README does not document retention controls for telemetry or the exact behavior of every third-party plugin.

Installing the Android release with signature checks

The README gives complete installation instructions only for Android in the available documentation. Download the APK from the repository's latest release page. After installation, the application can pull updates through its Repository section. Sideband is not distributed through app stores that prevent the developer from controlling APK signing, according to the README.

The project publishes SHA-256, SHA-1, and MD5 digests for the signing certificate. Compare the downloaded APK's certificate with the values below before installing it for the first time. If the certificate differs, the README explicitly says not to install the file. An APK obtained from another source should be rejected when these hashes do not match.

SHA-256 digest: 1c65f01f586a2b73ac4eb8bf48730b3899d046447185fd9d005685a4af20cdea
SHA-1 digest: 4ab9269c320c72f4e4057ec7ea5acade320c2a48
MD5 digest: 09afff8c505089a544ad2bf371c29422

For a first use, install the verified APK, open the program, and follow its included Guide before attempting to contact another user. The Android documentation also points to a community-provided Sideband Quick-start from RNS Moscow. The README excerpt does not provide Linux, Raspberry Pi, macOS, or Windows installation commands, so no package-manager or command-line procedure can be confirmed here.

Release artifacts versus the current source

The GitHub repository contains packaging infrastructure, including `setup.py`, `Makefile`, and `winbuild.bat`, but the README warns that this source tree is no longer updated. It states that development now happens over Reticulum and that the latest source is available there. This warning takes precedence over the repository's appearance as an active Python project.

The last repository push was on 2026-10-01, the same date as release 2.2.0. Earlier listed releases include 2.1.0 on 2026-08-28 and 2.0.1 on 2026-07-26. Packages and updates are still described as shipping through PyPI and `rngit`, while APKs, AppImages, wheels, and portable executable bundles continue to be published through the repository. Thus, artifact delivery remains possible even though the source repository is no longer the development endpoint.

That split has a direct adoption cost. A reviewer can inspect files such as `setup.py` and the `Makefile`, but cannot assume that this checkout represents the current application implementation. Upgrades should be checked against release artifacts and the source location named in the project's own channels, rather than inferred from commit recency alone.

CC BY-NC-SA 4.0 and vendor-free Android choices

The repository badge identifies CC BY-NC-SA 4.0 as the Sideband license, while GitHub classifies it as a custom license that does not fit its standard categories. The license and attribution, non-commercial, and share-alike conditions should be reviewed directly in the `LICENSE` file before the code, packages, or derivatives are used in an organizational or commercial context. This is a licensing boundary to evaluate, not legal advice.

The Android build is designed without Google-dependent or vendor-specific APIs and libraries. The README says it accesses raw Android OS APIs directly and is compatible with custom Android versions such as GrapheneOS and de-googled ROMs. This can make Sideband relevant to users avoiding proprietary mobile infrastructure. However, sideloading shifts responsibility to the user: there is no app-store review or update channel in the documented process, and the README makes certificate verification the first installation check.

Compared with a hosted messaging service, Sideband replaces account and server operations with network administration, peer discovery, propagation, certificate verification, and remote-access governance. Compared with a plain Reticulum utility, it adds a broad application interface, LXMF compatibility, calls, maps, telemetry, and plugins.

When Sideband is the wrong tool

Sideband is the wrong choice when convenience outweighs the need for a distributed Reticulum network. A user with no Reticulum path to peers cannot benefit from its lack of account infrastructure. Reachability must come from an existing compatible network, a transport instance, propagation, or another supported connection. The README does not promise that every LXMF destination can be contacted without intermediary reachability.

It is also unsuitable where a current, public GitHub source checkout is mandatory, where unrestricted commercial modification is required under the stated license terms, or where conventional mobile-store distribution is required. Teams that cannot inspect or control plugins should avoid enabling the plugin-driven remote-control surface.

Nomad Network is a real alternative within the documented ecosystem. It is also an LXMF-compatible client and is listed as capable of hosting Propagation Nodes. Sideband emphasizes messaging, calls, maps, telemetry, and remote control in one extensible client. Nomad Network is a more direct consideration when LXMF compatibility or propagation-node hosting is the primary requirement. Neither interface removes the need for a functioning Reticulum network.

Editorial conclusion

Sideband is appropriate for operators who already understand Reticulum and need LXMF messaging or LXST calls without a conventional Internet-based account service. It is a poor fit for users expecting normal store distribution, a public source mirror containing current development, or unrestricted commercial use. Before adoption, verify the latest 2.2.0 package and APK certificate, review the LICENSE file, and confirm that the selected LoRa, Packet Radio, WiFi, or I2P path can reach the required Reticulum peers.

Frequently asked questions

Official sources

1. Issues
2. markqvist/Sideband on GitHub
3. README
4. Releases