What Reticulum actually is

Before I touch a single piece of hardware, I wanted to make sure I actually understood what the Reticulum Network Stack (RNS) is — and what makes it different from the other mesh networking tools I’d come across. The short answer is that Reticulum isn’t a mesh radio protocol like LoRaWAN or Meshtastic. It’s a full networking stack — think of it as a replacement for the whole TCP/IP suite — that’s completely transport-agnostic. It can run over LoRa, packet radio, WiFi, TCP/IP, serial cables, even data-over-audio. The same Reticulum identity and the same application can move seamlessly across any combination of these at once. The LoRa nodes I’m building are just one interface type Reticulum can use, which is part of what makes this so interesting.

Three ideas make this stack genuinely different from typical networking, and I think they’re worth understanding before diving into the hardware:

• Identity, not address. Every node and every user has a cryptographic identity — a keypair. You don’t route to an IP address, you route to a destination hash derived from a public key. This means encryption and addressing are unified from the ground up, with no central authority handing anything out.
• No central authority. No DNS, no IP allocation, no certificate authority. Nodes discover each other and build routing tables organically through announcements. Nothing about this network depends on any external service staying online.
• Initiative-based routing. Nodes announce themselves periodically. Other nodes hear those announcements, remember the path, and that’s how packets get routed later. There’s no constant polling or handshaking overhead — which matters enormously on slow LoRa links where every transmission costs airtime.

The four logical layers in my build

When I mapped out what I’m actually building, it breaks down into four layers sitting on top of each other:

[ Application ]   Nomad Network / Sideband / custom scripts
        |
[ Reticulum (RNS) ]  rnsd daemon — routing, encryption, transport logic
        |
[ Interface ]     RNode firmware — turns LoRa radio into a packet modem
        |
[ Radio (PHY) ]   Heltec V4 + SX1262 chip, 868MHz EU ISM band

My Raspberry Pi 3 runs the middle two as a single process: rnsd (the Reticulum daemon) talks out over USB serial to the Heltec, which is running RNode firmware and only deals with the radio physics. The Heltec itself doesn’t know anything about identities, encryption, or routing — it just shuttles KISS-framed packets between USB and RF. All the intelligence lives in rnsd on the Pi. That clean separation is one of the things I find elegant about this design.

Why this matters for my plan

Right now my plan is: Pi (with RNode #1 on USB) ↔ RF ↔ standalone RNode #2. But for Node 2 to be useful, something needs to run Reticulum on the other end — otherwise it’s just a radio with no brain. My real options, which I’ll work through properly in Chapters 5 and 7, are:

1. Second compute near Node 2 — another Pi, a laptop, a phone running Sideband — attached to the Heltec via USB, giving me a second full site with complete app capability.
2. TCP/WiFi bridge firmware on the remote Heltec — bridges LoRa to a WiFi/TCP backbone without needing separate compute, but it’s a different, less mature firmware path I’ll explore later once I understand the basics.
3. Single Pi, two RNode interfaces — both Heltecs plugged into the same Pi via USB, which is actually the smartest way to start: prove everything works on the bench before deploying anything remotely.

Given where I’m starting, my plan is to validate everything with both Heltecs plugged into the Pi first, then physically separate them once I’m confident the radio link and configuration are solid.

The Transport concept — important for where this is going

One concept I want to flag early because it shapes everything that follows: a Reticulum node can be configured as a Transport Node, meaning it actively forwards traffic for others, not just sends and receives its own. My Pi 3, sitting at a fixed location with reliable power, is the natural candidate to become a Transport Node as I scale to 3+ nodes. This is what turns “two devices that can talk to each other” into actual mesh infrastructure — and it’s something I’ll enable in Chapter 6 and revisit properly when we get to Chapter 11.

---

That’s the conceptual foundation I’m working from. In Chapter 2, I’ll get into the physical hardware and the EU radio regulations I need to respect before anything gets powered on — including some rules around duty cycle and transmit power that will directly affect how I configure everything later.

• Chapter 0 — Introduction to Reticulum
• Chapter 1 — Concepts & Architecture
• Chapter 2 — Hardware & Legal Prep
• Chapter 3 — Prep the Raspberry Pi 3
• Chapter 4 — Flash RNode Firmware onto Heltec V4 (Node #1, attached to Pi)
• Chapter 5 — Flash the Second Heltec V4 (Remote Node)
• Chapter 6 — Configure Reticulum on the Pi
• Chapter 7 — Deploy the Remote Node
• Chapter 8 — First Contact: Testing the Link
• Chapter 9 — Running an Application
• Chapter 10 — Running rnsd as a Service
• Chapter 11 — Growing to 3+ Nodes & Next Steps
• Chapter 12 — Adding a Cloud Node
• Chapter 13 — Adding a Nomad Network Propagation Node