RFC: Reticulum Network Stack as a Decentralized Backhaul Layer for MeshCore #1736
Replies: 2 comments
-
|
I'm interested in this. My assumption was to not expect any particular engagement in the idea from Meshcore, but to just try and engineer it around the existing software stack. I was thinking you'd maybe want to run your Reticulum network on Halow for higher bandwidth links You'd try to get your MC 868Mhz MC device talking to your 865.2 Mhz Halow Reticulum device over UART maybe? 2.4Ghz and 5.8Ghz links in urban areas also a possibility for Reticulum.. Couple of us started chatting about this in a Reticulum Matrix chat channel |
Beta Was this translation helpful? Give feedback.
-
|
MeshCore added support for "bridges" a few months ago. Check discussion here: #454 I personally would like to see Reticulum as a bridge |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Background
MeshCore currently routes messages exclusively over LoRa repeater hops, with a maximum of 64 hops and no backhaul mechanism. This constrains network reach to RF propagation and provides no path for messages to traverse internet-connected segments or bridge geographically separated mesh islands.
This proposal outlines a practical approach to adding backhaul capability to MeshCore using Reticulum — a cryptography-first, infrastructure-free networking stack that supports LoRa, TCP/IP, serial, and other transports natively.
Proposed Integration
Reticulum RNodes — which use the same SX127x/SX126x radio hardware common in MeshCore deployments — can be configured to capture MeshCore LoRa packets and forward them across a Reticulum overlay network. This overlay can span TCP/IP links, additional LoRa segments, or any other Reticulum-supported transport, effectively giving MeshCore a backhaul path without modifying its core protocol.
This approach is currently in active demonstration and represents the most immediately feasible integration path, requiring no changes to MeshCore firmware.
A longer-term approach would involve native Reticulum interface support within MeshCore itself, enabling direct participation in Reticulum routing rather than relying on passive packet capture.
Interoperability Opportunity
Meshtastic is also being evaluated for Reticulum backhaul integration. If both platforms adopted Reticulum as a shared transport layer, a protocol translator could enable message exchange between MeshCore and Meshtastic nodes — a meaningful step toward cross-platform interoperability without requiring either project to compromise its native protocol design.
Questions for the MeshCore Team
Are there packet structure or encryption details in MeshCore's LoRa frames that would complicate passive ingestion via RNode?
Is there existing interest or prior discussion around adding backhaul support to MeshCore?
Would the MeshCore project be open to a native Reticulum interface as a future development target?
Is there appetite for collaborative development with the Meshtastic and Reticulum communities around a shared backhaul specification?
Current Status
RNode-based packet capture and Reticulum relay for MeshCore is in active demonstration. I am available to share technical details, configuration examples, and implementation notes to ground this discussion in concrete evidence.
Feedback from the MeshCore development team and community is very welcome.
Refercence:
Beta Was this translation helpful? Give feedback.
All reactions