Reticulum

"What's the matter with him? He's gone to plaid."

Reticulum is a cryptography-based networking stack for building wide-coverage networks with readily available hardware, that can continue to operate under adverse conditions. reticulum.network

Reticulum (RNS) is the protocol that turns a pile of LoRa radios into a working network. Every device has a cryptographic identity, every endpoint has a destination derived from it, and every packet finds its way with no central directory.

The five things to know

1. Identity is a keypair

Each device generates an X25519 + Ed25519 keypair on first boot. Concatenate both public keys (encryption key first), SHA-256, truncate to 16 bytes: that's the identity hash, e.g. 4e082f9561a41e9ef635c4149d88d20d. No registry, no signup, no recovery flow. Your private key is your Schwartz: hold it and you're you, lose it and that identity is gone. Make a new one in a heartbeat.

2. Destinations are addresses

A destination is identity + application-name + aspect. lxmf.delivery.<identity-hash> is an identity's messaging endpoint; nomadnetwork.node.<identity-hash> is its BBS endpoint. One identity, many destinations, one per app.

3. Paths are auto-discovered

A node sends an announce: a broadcast saying "this destination exists at this identity." Every transport node that hears it remembers it and floods it onward. Multi-hop paths build themselves: no DNS, no BGP, no central routing table.

Simplified, but faithful: only transport nodes re-broadcast an announce, on every interface with spare bandwidth (~2% per interface). Each relay bumps the hop count (max 128). Ordinary nodes hear it but never relay. Every node records a reverse path back to the origin.

4. Links are forward-secret encrypted sessions

Two destinations establish a link: an authenticated, end-to-end encrypted session with forward secrecy via ephemeral per-link keys. (For link-less LXMF delivery, Reticulum ratchets announce-time keys every ~30 min instead.) Page fetches, file transfers, LXMF delivery: all ride links.

5. The medium is irrelevant

LoRa, TCP, ethernet multicast, I2P, serial port, AX.25: Reticulum doesn't care which carries the bytes. A badge on LoRa and a phone on WiFi talk through an anchor node that bridges both, and neither end notices the cross-medium hop.

The stack

LXMF: the messaging layer

LXMF (Lightweight eXtensible Message Format) is the email-equivalent on top of Reticulum. Each message carries a title, body, and optional fields, signed by the sender's identity. Store-and-forward via propagation nodes means messages queue for offline recipients.

Eagle 5's "Open Channel" wall is a tiny LXMF service: send a message to its destination, it appends to a public file, the BBS page renders it. No web framework, no database, no signup. Post under any handle. The handle is just a label; your cryptographic identity is the only thing actually verifiable. Anonymous-ish by default, verifiable by anyone who checks.

Stamps: spam control with a real cost

LXMF has a proof-of-work mechanism called stamps (messaging layer, not core RNS). A destination can require incoming messages to carry a stamp of cost ≥ N bits: compute time spent generating the token. Cheap to send one, expensive to send a flood.

Why this stack, and not Meshtastic / Meshcore?

Meshtastic is a great LoRa mesh project: bigger community, more devices, simpler UX. It's also purpose-built for tiny text messages with a fixed application layer.

Reticulum is general-purpose. LXMF chat, BBS pages, file transfers, remote-shell sessions, and CTF challenge packets all ride the same primitives. That's why Eagle 5 can be a CTF playground first and a chat radio second.

Both stacks coexist on the same radio. The firmware's radio listen mode eavesdrops on Meshtastic and Meshcore beacons without changing config, handy for cross-protocol CTF challenges.

Read the source

github.com/markqvist/Reticulum ↗ (Python, AGPL) · markqvist.github.io/Reticulum/manual/ ↗ (official manual, well-written, longer than this page)

← mesh_networks · next: the_manual