From Interplanetary Internet to Reticulum.
There's a lineage in networking research that most mesh enthusiasts have never heard of, but that quietly explains why Reticulum works the way it does. It's called delay-tolerant networking (DTN), and it was born not from a desire to connect neighborhoods, but from the problem of connecting planets.
In the early 2000s, researchers working on NASA's Interplanetary Internet project faced a brutal constraint: when you're communicating with a spacecraft hundreds of millions of kilometers away, there is no such thing as a reliable end-to-end connection. Signals take minutes or hours each way. Planets rotate, occluding relay paths. Windows open and close. The entire mental model of TCP/IP breaks down: the handshake, the acknowledgment, the retransmission, the assumption that if you wait long enough a path will stabilize. None of it applies.
Internet pioneer Vint Cerf helped develop the initial Interplanetary Internet architecture. In 2002, Kevin Fall adapted those ideas for terrestrial networks and coined the term "delay-tolerant networking." The resulting Bundle Protocol became RFC 5050 in 2007, updated to BPv7 as RFC 9171 in 2022.
The answer they developed was the Bundle Protocol: a store-and-forward architecture where messages are treated as self-contained bundles, moved incrementally through a network, stored at each intermediate node, and forwarded opportunistically whenever a path becomes available. The assumption baked into DTN is not "the network will be there." It's "the network will eventually be there, in some form, for some duration, and we'll make use of it when it is."
That's a different assumption than the internet makes. And it turns out to be exactly the right assumption for off-grid mesh networks.
The scenarios DTN was designed for map almost perfectly onto the terrain where Reticulum operates.
LoRa links are range-limited and directional. Nodes move. Power goes out. A mountain sits between you and the nearest gateway. A community mesh at a festival has a thousand devices and intermittent congestion. A remote repeater is solar-powered and shuts down at night. In all of these situations, you cannot assume an end-to-end path exists when you need it. You can only assume that at some point, some path will exist, and that your message needs to survive long enough to traverse it.
Standard IP routing protocols (OSPF, BGP, even ad hoc protocols like AODV and DSR) are designed to establish a complete route first, then send data. When the route can't be established, they give up. DTN flips this: move the data forward as far as you can, store it where it lands, and continue when the opportunity arises.
Don't wait for a complete path. Use whatever fragments of path currently exist. That inversion, from "route then send" to "send then route," is the conceptual core of delay-tolerant networking, and it is precisely what makes mesh communication resilient in the real world.
Reticulum is not an implementation of the Bundle Protocol. It doesn't use RFC 9171. It doesn't have custody transfer, endpoint identifiers in the DTN sense, or the formal class-of-service markings defined by the IETF DTN working group. If you handed a classical DTN researcher a copy of Reticulum's spec, they wouldn't recognize it as belonging to their tradition.
But look at what Reticulum actually does.
At the transport layer, Reticulum establishes paths using announces, cryptographically signed broadcasts that propagate through the network, hop by hop, building up routing tables as they go. A node doesn't need a directory or a central authority. It listens for announces, builds a picture of what's reachable, and routes accordingly. When a destination goes quiet, the path ages out. When it comes back, new announces rebuild it.
The network is self-healing not because of a protocol enforcing it, but because every node is continuously re-advertising its existence. This is resilient by design. Not resilient because someone added a failover feature, but resilient because the baseline behavior assumes discontinuity.
Then there's LXMF, the Lightweight Extensible Message Format, which sits above Reticulum and handles messaging explicitly in the DTN tradition. LXMF has propagation nodes: network participants that store messages on behalf of destinations that aren't currently reachable. When you send a message over Nomad Network and your recipient is offline, the message doesn't fail. It lands at a propagation node, waits, and is delivered when the recipient next syncs. Hours later. Days later if needed.
LXMF's propagation node is store-and-forward DTN. Not as a bolt-on feature. As the intended behavior. The propagation node isn't a workaround for offline recipients — it's a first-class architectural feature.
What Reticulum gets right, and what classical DTN sometimes gets wrong, is proportionality. The Bundle Protocol is exhaustive. It was designed to handle interplanetary links with light-speed delays measured in minutes, asymmetric bandwidth, and no human in the loop. It carries that complexity forward into every deployment. Implementing BPv7 correctly is a substantial engineering undertaking, and the resulting systems are heavy.
Reticulum's designer, Mark Qvist, made different choices. The protocol is lean. Cryptographic identities are derived from public keys, which means there's no PKI infrastructure to maintain, no certificate authority to trust, no enrollment process. Routing is emergent rather than administered. The wire format is compact. The reference implementation runs comfortably on hardware that would struggle with a full Bundle Protocol stack.
The result is a system that achieves DTN-class resilience at a fraction of the operational weight — not because it cut corners, but because it correctly identified which parts of the DTN problem space it was solving for.
Humans communicating over LoRa links in the American Southwest don't need the same machinery as a Mars relay station. They need something that works when the internet doesn't, that doesn't require a sysadmin, and that can run on a $20 microcontroller. Reticulum delivers that.
There's a tendency in the mesh networking community to treat Reticulum as an interesting curiosity: a novel protocol that does some clever things with cryptography and works over LoRa. That framing undersells it.
Reticulum belongs to a forty-year tradition of serious networking research aimed at the hardest connectivity problem: how do you move information reliably through a network that can't guarantee end-to-end connectivity? The Bundle Protocol addressed that problem for space. UUCP addressed an early version of it for pre-internet store-and-forward mail. Reticulum addresses it for the growing population of people building infrastructure outside the reach of commercial networks.
Understanding Reticulum as a practical DTN changes how you deploy it. You stop thinking about it as a degraded version of the internet, slower and less reliable, making do. You start thinking about it as a system purpose-built for discontinuous networks, operating exactly as intended. The announce-based routing isn't a limitation; it's a deliberate choice to make the network self-organizing without central coordination.
The internet was built for a world where connectivity is assumed and resilience is added after the fact. Reticulum was built for a world where disruption is assumed. Connectivity is seized when it appears. That's a superior network, because it fits the world most people actually live in.
Guides, hardware recommendations, and free configuration documentation are all at nodestar.net.