4.1 Reticulum, LXMF and RNode Bridge

Reticulum, LXMF and RNode Bridge

Language: English. Chinese version: 4.1 Reticulum, LXMF and RNode Bridge (中文)

This page exists to explain Trail Mate’s current Reticulum-related support without collapsing several different concepts into one sentence. Writing only “supports Reticulum” is not enough, because in Trail Mate, Reticulum, LXMF, and RNode Bridge are not the same layer and they are not used in the same way.

Three Different Concepts First

Reticulum is the network stack. It is not only a message format. It involves identity, announce behavior, path discovery, proof handling, links, resources, and propagation behavior.

LXMF is a message and application-layer mechanism that runs on top of Reticulum. In Trail Mate, choosing LXMF means the device itself is running a device-side Reticulum/LXMF runtime.

RNode Bridge is not “another kind of LXMF”. It is a host bridge mode whose purpose is to let an external Reticulum host use the Trail Mate device as an RNode/KISS modem.

What They Mean Inside Trail Mate

LXMF: native device-side mode

In LXMF mode, the device itself is responsible for things such as:

• holding a local identity
• sending and receiving announces
• maintaining peer discovery and peer recall
• handling Reticulum path-related state
• handling LXMF text and related app data
• feeding results back into local contacts, chat, and UI state

This means it is not just a private chat mechanism that happens to resemble LXMF. It is a real attempt to host a device-side Reticulum/LXMF-compatible path.

RNode Bridge: external-host modem path

In RNode Bridge mode, the device’s role shrinks toward the carrier layer:

• it provides an RNode-compatible LoRa carrier
• it exposes a KISS modem interface over USB CDC
• it lets the external Reticulum host control identity, announce behavior, LXMF logic, and broader network-stack behavior

That is why RNode Bridge should not be described as a local on-device Reticulum UI mode. When you choose it, protocol ownership moves to the external host.

What Is Already Implemented

The repository and docs/RETICULUM_LXMF_RUNTIME_ALIGNMENT_PLAN.md already make it clear that Trail Mate’s LxmfAdapter is not just scattered placeholder code. The current baseline includes:

• Reticulum announce validation and caching
• path request initiation and path-response handling
• announce cache replay
• HEADER_2 multi-hop forwarding
• reverse-path proof relay
• local link session handling
• link request relay
• resource advertise, request, hashmap, part, and proof flow
• propagation offer and get request handling

That is why the Reticulum route should no longer be described as “planned for later”.

What It Still Should Not Be Described As

Even with that progress, the correct wording is still careful:

• Trail Mate already has a real device-side LXMF path
• it also already has a real RNode Bridge path
• the current engineering work is more about runtime lifecycle and modular cleanup than about “does this protocol path exist at all”
• it still should not be described as full desktop parity with upstream Python Reticulum or LXMF implementations

The point is that “real implementation exists” and “every upstream desktop feature is already equivalent” are not the same claim.

Current Carrier and Hardware Boundary

The current architecture documents define this route around an existing ESP-side RNode-compatible radio path carrying device-side Reticulum and LXMF behavior.

Two practical conclusions follow:

• the current LXMF route is a real capability on top of an existing ESP-side carrier path
• this is not a completely separate radio layer unrelated to the rest of the project; it reuses an RNode-compatible raw LoRa carrier

How To Think About Configuration

In the current code, both LXMF and RNode Bridge use a separate rnode_config for the carrier layer. That is different from Meshtastic’s Region / Channel / PSK model and also different from MeshCore’s region preset model.

The practical interpretation is:

• LXMF and RNode Bridge care about RNode carrier settings such as BW, SF, CR, TX Power, and Override Freq
• they should not be described through Meshtastic channel semantics
• validating RNode Bridge means confirming that the external host really recognizes the device as an RNode/KISS modem, not checking whether the local device chat page behaves like Meshtastic

When To Choose LXMF

Choose LXMF when the device itself is meant to become a Reticulum/LXMF node and handle identity, discovery, chat, and protocol processing locally.

This path fits best when:

• you want to study or use device-side Reticulum/LXMF behavior
• you do not want the full protocol authority to live on an external host
• you want contacts, chat, and local UI to connect directly to the Reticulum runtime on the device

When To Choose RNode Bridge

Choose RNode Bridge when the host, not the handheld, is supposed to run the real Reticulum stack.

This path fits best when:

• you already have an external Reticulum host
• you need a KISS or RNode bridge
• you want the more complete host-side Reticulum logic to remain outside the device

The Misunderstandings To Avoid

• “supports Reticulum” is not enough by itself
• LXMF is not the same as RNode Bridge
• RNode Bridge is not a local on-device chat mode
• “real implementation exists” is not the same as “complete desktop parity”
• having a Reticulum route does not mean the system automatically mixes Reticulum, Meshtastic, and MeshCore at runtime

Related Pages

• [[4. Protocols & Data]]
• [[3.5 Configuration Guide]]
• [[11. Architecture]]
• [[15. Logging and Debugging]]