RFC: Reticulum Network Stack as a Decentralized Backhaul Layer for MeshCore

[GrayHatGuy]

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

1. Are there packet structure or encryption details in MeshCore's LoRa frames that would complicate passive ingestion via RNode?

2. Is there existing interest or prior discussion around adding backhaul support to MeshCore?

3. Would the MeshCore project be open to a native Reticulum interface as a future development target?

4. 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:

• Meshtastic Discussion #460
• Meshcore Discussion #37
• Meshcore Discussion #117

[samuk]

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

[pramodhrachuri]

MeshCore added support for "bridges" a few months ago. Check discussion here: #454
There is official support for ESPNow and RS232 as bridges. Check this: https://github.com/meshcore-dev/MeshCore/tree/main/src/helpers/bridges
The dev team is against tcp/ip bridging. Check this comment: #37 (comment)
A community member made a fork to support MQTT as a bridge. Check this repo: https://github.com/vrybdpkt/MeshCore

I personally would like to see Reticulum as a bridge

[artbotterell]

+1 for Reticulum bridging. Personally I think the concern about Internet bridging is a bit overblown... if it actually becomes a problem surely there are more constructive ways to mitigate it than a reflexive prohibition... even if such a thing were feasible, which I rather doubt.

[LitBomb]

@artbotterell

Personally I think the concern about Internet bridging is a bit overblown... if it actually becomes a problem surely there are more constructive ways to mitigate it than a reflexive prohibition... even if such a thing were feasible, which I rather doubt.

Some people have already been bridging LAX to SEA over the Internet. It is an obvious bridge because SEA and LAX use different presets. SEA repeater adverts show up on LAX companions' map and vice versa. This would not have happened if it was tropo effect via RF.

[samuk]

I have a bit of hardware WIP to help facilitate this https://github.com/samuk/awesome-meshcore/blob/main/open_hardware.md

@GrayHatGuy has a repo with WIP 2.4Ghz code for uReticulum he may invite you to

[artbotterell]

Thanks, Samuk... that's very interesting. I've been hanging on to a couple of HaLow dongles with a mind to experiment with those, but I have a number of ESP32 gizmos and assorted LoRa boards lying around... and a box full of Pi Zero Ws.

[GrayHatGuy]

Basically I have a alpha code set and HAL built for T3S3 using sx1280 and LR1121 also esp32s3 Xiao with LR1121 for 2400MHz Lora.

The overall repo uses microreticulum as a lib and RTNode as a fork. All the variants using <2400 are good to go. The RTNode variants are listed under the env of Boundary Mode and are going gtg.

I'm still running verification tests on the 2400MHz. So anything with LR1121 or SX1280 is a WIP.

https://github.com/GrayHatGuy/RTNode-2400

[samuk]

I fed your doc and a doc I'd been working on into a word guessing machine and it came out with this. Some of it may have value https://github.com/samuk/Reticulum/blob/master/docs/meshcore-bridge.md

[GrayHatGuy]

I'm thinking I could do this in 1 MCU with dual radios. A sx1262 using the 40 pin B2B header on the xiaoesp32s2 and a second wio sx1262 connected to the perimeter pins. I have ran it thru a pin assignment and it is feasible.

Just giving options...
I'm still digesting the results of the word guessing output but first skim it looks feasible but I need to dig deeper.

[artbotterell]

CoreNet Rev 0.2 — thanks to everyone whose feedback shaped this round.

The big reframe: CoreNet is now positioned as a routing and addressing layer that sits above whatever wide-area transport you're already using — MQTT, Reticulum, TCP, whatever comes next. Not a replacement for existing bridges; a convergence point above them. LXMF/Reticulum is the reference v0.1 transport, not the defining idea.

A few specifics that now have concrete shape:

• @KD6O@SEA hello — cross-zone DM addressing from any stock MeshCore client. No firmware or app changes.
• who / channels — pull-based discovery with privacy defaults; nothing gets spammed onto local RF.
• corenet-ctl — dedicated control channel for federation activity, including signed identity-conflict reports so collisions don't fail silently.
• Any channel member (not the bridge operator) can ::corenet publish:: or ::corenet unpublish:: a channel's discoverability via an in-channel control message.

New normative spec alongside the README; the original is archived.

https://github.com/artbotterell/CoreNet

If something feels wrong, this is a good thread for it — or GitHub Discussions/Issues for longer threads.

[samuk]

I gave your latest version to the complicated rocks that guess words and regurgitated this.

https://github.com/samuk/Reticulum/blob/master/docs/meshcore-bridge.md

[artbotterell]

Hi samuk, Art Botterell (KD6O) here — the all-too-human co-author of the CoreNet spec. Just read your MeshCore-Reticulum Bridge Node v5 and wanted to reach out. This is the first hardware implementation effort I've seen against CoreNet's architecture, and it's a thoughtful piece of engineering. A few specific observations: - Your RTNode-2400 / microReticulum choice is an interesting one. CoreNet's architecture is implementation-agnostic, but our reference implementation to date has been Python on a Pi-class host, for no particular reason. A purpose-built dual-MCU embedded bridge is a meaningfully different deployment class, and you've done real work identifying the components that fit and the integration patterns that work. - Your §4.2 resolution of the earlier per-node HKDF derivation in favour of the bridge-as-endpoint model matches the CoreNet spec. Good confirmation that the abstraction is clear enough for parallel efforts to converge. - Your §6.3 manifest signing detail is more concrete than CoreNet's current "manifests are signed" hand-wave. Genuinely open question between us: does that kind of detail belong in the federation protocol, or is it implementation territory where different targets might legitimately differ? Worth a conversation. - §5.5 admin command filtering and §5.6's honest treatment of the missing `CMD_SEND_ACK` are both the right engineering posture. The ACK limitation in particular seems worth raising with the MeshCore core team as a companion-protocol extension request. A couple of places where harmonising between the two specs might help: - Region tag length: your §5.4 says 8 bytes; CoreNet §5.2 allows up to 16. Cross-implementation interoperability needs one answer. - Position precision: your quantisation-radius-in-metres (§5.4) is more operator-meaningful than CoreNet's microdegree representation. Worth considering for the next CoreNet revision. Happy to continue discussion wherever works — issues on the CoreNet repo, your repo, or anywhere else you prefer. A real hardware implementation is exactly what validates that the federation protocol holds up under engineering contact, which is the outcome the Rev 0.2 paper was hoping for. — Art / KD6O

…

On Apr 19, 2026, at 15:38, samuk ***@***.***> wrote: I gave your latest version to the clever rocks that guess words and regurgitated this. https://github.com/samuk/Reticulum/blob/master/docs/meshcore-bridge.md

[samuk]

Art — good to hear from you, and thanks for reading it. It's great to have the core spec to inform this work.

Sadly I've outsourced most of my thinking to the complicated silicon, so I'll let it reply below;

The §4.2 convergence was embarrassing in hindsight — we'd been solving an imaginary problem for several iterations before reading your source code.

On manifest signing: we've logged it as an open question (Q18) and agree the wire format and verification procedure need coordinating before two independent implementations try to verify each other. Reticulum identity signing is the natural choice on this hardware since the key is already in NVS, but whether that detail belongs in the federation spec is your call.

Region tag was a error on our part — your grammar says 1*16 and we had 8 bytes. Fixed to 16, payload up to 114 bytes.

On position: the metres field is an operator-legibility choice for constrained hardware config. MCU 2 converts to microdegrees before any LXMF response goes out, so the wire stays in CoreNet's native units. If it's useful for the next CoreNet revision, feel free.

GrayHatGuy has flagged the SX1280 variants are still under verification — we've added a WIP caveat to the spec. His single-MCU suggestion (SX1262 & SX1280 on one ESP32-S3) is noted as a parallel path worth evaluating; main trade-off is losing the clean MCU boundary between MeshCore and Reticulum.

/rocks

Human:

On balance I quite like the MCU separation, particularly as the second MCU can be ultra-low power nrf52.

I've updated our doc to fix the errors: https://github.com/samuk/Reticulum/blob/master/docs/meshcore-bridge.md

As an aside I've also adapted WIP hardware a bit so that more than one daughter board can be chained together for multiple batteries, the hardware side still needs some good review before a first test fabrication.

I wonder about running SPI between the two XIAO footprints, would enable the single MCU use case. Pins are tight on the XIAO though

Thanks Sam (&robot)

[artbotterell]

Sam — The §4.2 embarrassment is entirely mutual — we'd been reasoning about a problem that wasn't there either. Three things we can close: **Region tag** — 16 bytes, done. Thank you for the fix; that one was straightforwardly our error. **Position** — the metres-for-config / microdegrees-on-wire split works cleanly for transmission. One question before we close it: what do receivers currently do with the position field? If it's display-only (render a dot), the wire format is settled. If receivers are expected to render an uncertainty circle — "somewhere within ~1km" — then the intended radius needs to travel with the position, and metres is the right unit for that field. The reason it matters: truncating in microdegree space produces latitude-dependent ovals, not circles; a receiver drawing a radius needs to know the physical extent the sender intended. Happy to add a radius field to §11.3 and specify the quantisation algorithm if that's the direction, or leave it as an implementation note if display is dot-only for now. **Manifest signing** — we'll put it in the spec. Reticulum identity signing (key from NVS) is the right answer: it's already present on the hardware, it gives us a concrete verification procedure before two implementations try to handshake, and leaving it underspecified invites silent interop failures. We'll draft §6.x naming it as the required mechanism — signing *what* and *with what key type*, implementation storage left to implementations. Will share a draft before committing. On hardware: the nrf52 argument for keeping the MCU boundary is compelling, particularly the standby power profile. The SPI-between-XIAO-footprints idea for single-MCU is worth prototyping as a parallel path — if pins are genuinely too tight it answers the question cleanly. Either way it doesn't block the spec. Looking forward to the first test fabrication. 73 de Art KD6O

…

On Apr 20, 2026, at 01:37, samuk ***@***.***> wrote: Art — good to hear from you, and thanks for reading it. It's great to have the core spec to inform this work. Sadly I've outsourced most of my thinking to the complicated silicon, so I'll let it reply below; The §4.2 convergence was embarrassing in hindsight — we'd been solving an imaginary problem for several iterations before reading your source code. On manifest signing: we've logged it as an open question (Q18) and agree the wire format and verification procedure need coordinating before two independent implementations try to verify each other. Reticulum identity signing is the natural choice on this hardware since the key is already in NVS, but whether that detail belongs in the federation spec is your call. Region tag was a error on our part — your grammar says 1*16 and we had 8 bytes. Fixed to 16, payload up to 114 bytes. On position: the metres field is an operator-legibility choice for constrained hardware config. MCU 2 converts to microdegrees before any LXMF response goes out, so the wire stays in CoreNet's native units. If it's useful for the next CoreNet revision, feel free. GrayHatGuy has flagged the SX1280 variants are still under verification — we've added a WIP caveat to the spec. His single-MCU suggestion (SX1262 & SX1280 on one ESP32-S3) is noted as a parallel path worth evaluating; main trade-off is losing the clean MCU boundary between MeshCore and Reticulum. /rocks Human: On balance I quite like the MCU separation, particularly as the second MCU can be ultra-low power nrf52. I've updated our doc to fix the errors: https://github.com/samuk/Reticulum/blob/master/docs/meshcore-bridge.md As an aside I've also adapted WIP hardware a bit so that more than one daughter board can be chained together for multiple batteries, the hardware side still needs some good review before a first test fabrication. I wonder about running SPI between the two XIAO footprints, would enable the single MCU use case. Pins are tight on the XIAO though Thanks Sam (&robot)