Reticulum is a way to build data networks across different communication media. LoRa can be one of those media, but Reticulum is neither a particular radio nor a single worldwide network that automatically becomes available when you switch on a board. You choose the links and applications; the stack provides mechanisms for addressing, encrypted communication and transport.

That makes Reticulum interesting for small local experiments, community infrastructure and networks that mix slow radio links with faster connections. It also means that selecting a “Reticulum board” without deciding what runs on the host can leave out half the system.

Separate the application, stack and radio

In a common LoRa setup, the application and Reticulum run on a phone or computer, and a connected RNode supplies the radio interface. Some integrated products combine these pieces, but a supported radio board alone is not necessarily a complete messenger. The Reticulum starting guide introduces the applications, while the hardware chapter describes the interfaces.

How destinations and paths differ from an IP network

Applications communicate through destinations rather than the familiar combination of an IP address and port. A destination is associated with an application endpoint; cryptographic identity is part of how ordinary single destinations are identified. An identity and an application’s messaging address are related concepts, but you should exchange the address the application actually asks for.

Announces make destinations and their public-key information discoverable. Transport nodes can help carry traffic across multiple hops. These mechanisms do not replace the physical links: an unreachable radio segment remains unreachable. Start with two endpoints before adding transport infrastructure. The Reticulum architecture chapter explains the underlying destination and link types.

RNode compatibility is specific

RNode is a radio interface, with firmware available for supported hardware. A LoRa chip or a product title containing ESP32 is insufficient proof of support. Check the precise board revision, radio chip, frequency version and supported firmware target. USB, Bluetooth and other connection options also depend on the specific implementation and host.

Installing RNode firmware over Meshtastic firmware changes the device’s role. It does not make the two protocols understand each other, and you should not expect both stacks to share one ordinary firmware installation. Back up useful settings and follow the supported flashing and recovery procedure for the exact board. Use the RNode firmware project as the compatibility reference, not a visually similar product photograph.

Start without radio, then add it

A productive first experiment separates software questions from radio questions. Install a supported application on two suitable devices and use a documented local-network interface. Exchange the application addresses, send a message both ways and learn where delivery status is shown. This establishes that your applications and identities work before you introduce antennas and serial ports.

Next, add two compatible RNodes with suitable antennas, data connections and stable power. Configure matching radio parameters using the current interface documentation. Use the correct regional conditions for the installation; example frequencies in a manual are not automatic permission to transmit. Keep a record of the working parameters and host-device pairing.

Finally, isolate the radio path. Disable or disconnect other Reticulum interfaces that could carry your test message, while keeping whatever local connection the host needs to talk to its RNode. Send a new message each way. A message arriving while both computers also share an IP network does not demonstrate that it crossed the LoRa link.

LXMF and offline delivery are separate from routing

LXMF is a messaging protocol built on Reticulum. It supports messaging patterns including direct delivery and propagation, where an appropriately configured propagation node can hold messages for later retrieval. That is useful when endpoints are not continuously online, but it is not magic storage in every radio.

A Reticulum transport node and an LXMF propagation node perform different jobs. One helps move network traffic; the other supports an application-level delivery mechanism. Decide whether you need one, both or neither. An offline recipient needs an available delivery arrangement and a later opportunity to retrieve messages. Read the LXMF project documentation before relying on store-and-forward behaviour.

Build a small topology deliberately

Consider two workshops with local LoRa users and an existing IP link between the buildings. Reticulum can use different configured interfaces in the same overall design. The IP segment can carry traffic between locations, while LoRa serves nearby radio users. This does not make the result independent of the IP segment: unplug it and the workshops may become separate networks.

Draw each dependency explicitly: host, radio, power source, antenna and backhaul. Then ask what happens when each one fails. A useful design may tolerate some outages while accepting others. Label that honestly rather than describing any mixed network as completely off-grid.

Use stable, well-connected systems for transport where it is needed. Enabling transport everywhere is not inherently better, especially when maintenance traffic must cross a slow radio link. The network-design chapter discusses transport roles and the cost of carrying announces between links with very different capacities.

Security boundaries deserve a drawing too

Reticulum’s cryptographic mechanisms are central to its design, but “encrypted” is not a promise that nothing can be observed or that every connected application is safe. Devices hold keys; compromised endpoints can expose information. Radio activity and the operation of a gateway may remain observable. Verify identities through a trusted method when it matters, and protect identity backups as sensitive material.

Most importantly, an application bridge that decrypts and reformats a message creates a new trust boundary. It is different from forwarding an encrypted Reticulum packet. Draw where plaintext exists, who operates that system and which part of the route has which protection. Do not assume that a message is end-to-end encrypted merely because both endpoint applications use Reticulum.

Advanced example: Reticulum and an experimental HF bridge

The video The Open Source Internet Is Here explores an experimental bridge using HF radio. Around 27:20 it explains terminating encryption at a gateway; around 57:45 it describes a working bridge. At 56:06 the creator explicitly says the intended skywave test was not completed. It is an instructive experiment, not evidence of a completed intercontinental Reticulum link.

The example illustrates why a gateway, a radio path and end-to-end protection must be considered separately. It also uses different equipment and a different regulatory setting from an ordinary LoRa installation. Do not copy its amateur-radio settings or legal conclusions into Denmark or Sweden without checking the applicable rules. The video is inspiration for advanced experimentation, not an eBits-supported turnkey configuration.

Troubleshoot one layer at a time

Choose small test messages and record the interfaces used, delivery status and elapsed time. Repeat after restarting each host. Measure the complete setup’s power demand; a low-power radio attached to an always-on computer is still an always-on computer system.

What to tell us before choosing hardware

Tell eBits which application and host you intend to use, whether the first link is LoRa or IP, the locations to connect and how the system will be powered. We can help narrow the component choices and identify what needs compatibility checking. We do not treat every LoRa-capable board as a verified RNode target. Contact us about the project, and compare LoRa fundamentals with Meshtastic network design before selecting a protocol.

Reviewed 28 September 2026. This is a technical planning guide, not a claim that eBits has field-tested every topology or stocks a complete HF system. Follow the current upstream documentation for installation and supported hardware.