RFC: Reticulum Network Stack as an Alternative Backhaul to MQTT

[GrayHatGuy]

Background

Meshtastic's current internet backhaul relies on MQTT over TCP/IP. While functional, this introduces a dependency on a centralized broker — a structural tension with Meshtastic's otherwise decentralized design. Broker availability becomes a point of failure, and the transport layer adds no encryption beyond what Meshtastic provides at the packet level.

This proposal asks the Meshtastic development team to evaluate Reticulum as an alternative backhaul transport: one that is infrastructure-free, cryptographically strong, and transport-agnostic.

---

What is Reticulum?

Reticulum is an open-source networking stack designed for resilient communication over low-bandwidth, high-latency, and heterogeneous links. It supports LoRa (via RNode), TCP/IP, serial, I2C, and other transports natively. It provides end-to-end encryption via Curve25519 and AES-128-CBC, path-independent addressing, and requires no central broker, DNS, or PKI infrastructure to operate.

---

Proposed Integration Options

Option A — Native Backhaul Interface (Preferred) A new Reticulum-backed interface type, analogous to the existing MQTTClient interface, would be implemented to connect Meshtastic's backhaul system to a local or remote Reticulum instance via the RNS Python API. Meshtastic packets would be encapsulated for transport over whatever interfaces the Reticulum instance has available — LoRa, TCP/IP, or otherwise — without any broker dependency.

This is the cleaner architectural approach and the one most consistent with Meshtastic's decentralization goals.

Option B — RNode Packet Ingestion (Gateway/Bridge Use Case) A Reticulum RNode, using the same SX127x/SX126x hardware common in Meshtastic deployments, could passively ingest Meshtastic LoRa traffic and forward it into a Reticulum network segment. This approach is more complex, requires frequency and airtime coordination, and is better suited to a gateway or bridge role rather than primary backhaul.

---

Interoperability Opportunity

MeshCore is also being evaluated for Reticulum backhaul integration. A shared Reticulum backhaul layer between Meshtastic and MeshCore would create a practical foundation for cross-platform message exchange via a protocol translator — without requiring either platform to modify its native protocol. This represents a meaningful interoperability opportunity for the broader off-grid messaging ecosystem.

---

Questions for the Meshtastic Team

1. Is a Reticulum interface type considered a viable addition to Meshtastic's backhaul architecture, and if not, what are the primary objections?

2. What are the anticipated protocol mapping challenges between Meshtastic's portnum/packet structure and Reticulum's destination and link-layer model?

3. Is there existing interest in reducing or eliminating the MQTT broker dependency in the backhaul system?

4. Would the Meshtastic project be open to collaborative development with the MeshCore and Reticulum communities around a shared backhaul specification?

---

Current Status

Reticulum-based backhaul is currently in active demonstration for MeshCore using RNode packet ingestion. The Meshtastic integration is at the proposal stage. I am happy to provide implementation notes, packet captures, and configuration details to support the feasibility discussion here.

I welcome feedback from the Meshtastic development team and the broader community.

---

Each version shares a common technical foundation but is framed around what matters most to each audience: the Reticulum post focuses on API and interface design questions; the MeshCore post leads with the immediate, no-firmware-change demonstration already underway; and the Meshtastic post directly addresses the MQTT centralization concern, which is the most likely point of traction with that team.

Refercence: Meshcore Discussion #1736