Networking layers in Python peer-to-peer libraries
Choosing a Python peer-to-peer library starts with the layer you need, because “peer-to-peer networking in Python” covers several different jobs. One library finds a printer on the office network. Another opens a Bluetooth LE connection to a sensor. Another routes encrypted packets across a chain of radios. The layers are:
- A link. Moving bytes between two devices in direct reach, over Bluetooth LE, a LAN or a serial line.
- Discovery. Finding which devices and services are nearby before connecting.
- Routing. Getting a message to a device that is not in direct reach, through other devices that relay it. That is what makes a network a mesh.
- Security and delivery. Encrypting end to end, so relays cannot read what they carry, and confirming delivery or retrying when a path disappears.
A link library leaves routing, encryption and delivery to you. A full stack provides them but asks you to adopt its protocol on every device.
Python peer-to-peer and mesh libraries
Reticulum, py-libp2p, Bleak and Bless, python-zeroconf, the Meshtastic Python API and the Offline Protocol SDK each cover a different layer.
Reticulum (pip install rns). A self-configuring, encrypted mesh networking stack whose reference implementation is the Python package. Its PyPI page lists multi-hop routing over heterogeneous carriers, including Ethernet and IP, LoRa through an RNode, packet radio TNCs and serial ports. It is a complete network in its own right, with its own addressing, and is published under the Reticulum License. What is Reticulum? covers how it works.
py-libp2p (pip install libp2p). The Python implementation of the libp2p stack used by IPFS and other peer-to-peer systems. Its PyPI page classifies it as beta and says the core features are stable while it progresses toward production readiness. TCP, QUIC and WebSocket transports are marked complete, while WebTransport and WebRTC are prototypes. It assumes an IP network between peers, so it does not reach a device over Bluetooth.
Bleak and Bless. Bleak is a Bluetooth LE GATT client for Windows, Linux, macOS and Android, MIT licensed. It connects to devices that act as GATT servers and does not act as one itself. Bless is a GATT server library written to go with Bleak, so a Python program can advertise its own services. Together they give Python both Bluetooth LE roles, with no routing, encryption between devices or retry on top.
python-zeroconf (pip install zeroconf). A pure Python implementation of multicast DNS service discovery. It announces and finds services on a local network with no DNS server, as described in mDNS and DNS-SD. It is a discovery tool; the connection that follows is yours to make.
The Meshtastic Python API (pip install meshtastic). A Python API and command-line shell for talking to Meshtastic devices. The LoRa radios form the mesh, and Python configures a radio and sends and receives through it over USB, Bluetooth or the network. Every node needs Meshtastic hardware.
The Offline Protocol SDK (pip install offline-protocol-sdk). The Python package of a mesh SDK whose Rust core also runs inside iOS and Android apps. A Python host runs a full peer: an Ed25519 identity, MLS (RFC 9420) encryption for messages and groups, relay across several hops, acknowledgments and retries, replicated documents and service discovery. Its Bluetooth LE manager uses Bleak as a central and Bless as a peripheral, and the peripheral role is not available on Windows. A peer-stream manager connects hosts over TCP on a LAN, finds them through DNS-SD with the optional lan extra, and since version 0.28.0 is how an iPhone on the same network reaches a Python host, joined by Android phones in 0.29.0. The package also ships offline-protocol-service, which lets several local applications share one engine over JSON-RPC 2.0 on a WebSocket and starts every transport its configuration enables, and file stores sealed under a store key for a host with no keyring. With the http extra the service also serves an HTTP front, so a program that does not import the SDK can call a service on another device with an ordinary HTTP request. It is free under AGPL-3.0-only, with a commercial license for closed-source use.
Python mesh library comparison
Reticulum and the Offline Protocol SDK route across several hops themselves, py-libp2p does it through overlays such as gossip, Meshtastic leaves it to the radios, and Bleak, Bless and python-zeroconf work only in direct reach.
| Layer | Multi-hop | Transports | License and status (as of October 2026) | |
|---|---|---|---|---|
| Reticulum (rns 1.5.7) | Full mesh stack | Yes | IP, LoRa, packet radio, serial | Reticulum License |
| py-libp2p (0.8.0) | Peer-to-peer stack over IP | Through overlays such as gossip | TCP, QUIC, WebSocket | MIT and Apache-2.0; beta |
| Bleak (3.0.2) and Bless (0.3.0) | Bluetooth LE link | No | Bluetooth LE | MIT |
| python-zeroconf | LAN discovery | No | Multicast DNS | LGPL-2.1-or-later |
| Meshtastic API (2.7.11) | Client for LoRa radios | In the radios | LoRa, through a device | GPL-3.0-only |
| Offline Protocol SDK (0.30.0) | Full mesh SDK, also on phones | Yes | Bluetooth LE, LAN streams, internet relay, gateway daemon | AGPL-3.0-only or commercial; beta |
Choosing a Python mesh networking library
The right Python mesh networking library depends on what your program has to reach: other Python machines on one network, radios over long distances, a Bluetooth sensor, or phones in the field.
- Only Python machines on one network, and you want a standard stack? py-libp2p, or plain sockets with python-zeroconf for discovery.
- Radios and long distances, with no internet? Reticulum, or Meshtastic if your team already carries Meshtastic devices.
- A Python program that reads a Bluetooth sensor? Bleak, and Bless if the program must also be the peripheral.
- A gateway, desktop tool or service that has to exchange encrypted messages and shared state with phones in the field? A mesh SDK that runs on both, such as Offline Protocol, so the Python host and the phones speak one protocol. Check the wheel list against your hosts first.
Whatever you choose, test on the hardware you will deploy: Bluetooth stacks differ across Linux distributions and laptop chipsets, and a protocol that works between two desktops can behave differently next to phones in the background.