Linux in a Bit's Stuff
Reticulum is a per-packet encrypted mesh network that flood routes only one kind of packet, called an announce. Announces tell each node in the network the “next hop” to get to every other node on the network. Everything else is routed along a single path determined by those “next hops,” resulting in very efficient routing overall.
Offline communication networks are often hard to establish, and previously, if you wanted to set up anything larger than a small scale community mesh network, you used to be basically out of luck, let alone if you wanted to do so on any kind of budget. Luckily there's a fantastic project that does exactly that. It's called Reticulum, and it's the most elegant solution for true global scale peer-to-peer mesh networking I've seen.
Reticulum has potential to become a truly offline replacement for the internet working over almost every networking medium, including LoRa and packet radio. It's still in beta development, but already works astonishingly well. It is a full network stack down to the physical layer. Everything is end to end encrypted per packet, incredibly efficient, and ingeniously simple.
It enables self-organizing, unmanaged networks scaling from a small community to a global scale at relatively low cost. Reticulum is a network stack that can be used to build any number of networks that can freely interconnect and cannot be killed, surveilled, or censored.
Reticulum does not require you to store other people's data in some kind of distributed file system or data store; it is exclusively a network stack. There is no reliance on any kind of cryptocurrency or blockchain, and it is incredibly lightweight supporting very high latency and extremely low bandwidth mediums as well as much faster connections.
Before I show you how to get set up, we must answer an important question; exactly how does Reticulum work, and what makes it so special?
Let's start with establishing some basic terminology.
Destinations replace the concept of "endpoints" that IP and similar protocols use. All you need to know right now is that Reticulum Destinations allow programs to receive data and are essentially arbitrary when compared to IP Addresses. A single physical device can host multiple different destinations. There are a few types of destinations:
Destinations do not know anything about the network beyond their immediate neighbors. They can move around a network at will and can even move to completely separate networks and still become reachable. To become reachable, a destination simply needs to send an announce on any network it is part of.
Announces are special signed packets that contain a destination's address, public key, and some other information needed to establish end-to-end connectivity to said destination. They are propagated throughout a network by Transport Nodes and allow Reticulum to form multi-hop connections between destinations.
A Transport Node is a destination that is set to route data via a single configuration option. Not all destinations route traffic because this requires exponentially increasing bandwidth and decreased reliability in larger networks just to support Transport Nodes that will never route anything. Reticulum can technically work without Transport Nodes, but only directly connected destinations are able to communicate without them.
A Peer is just a standard destination that does not route data, only sends and receives. Transport Nodes can route traffic but are otherwise identical to normal Peers.
An Interface is a connection over any medium between two or more destinations.
And finally Identities represent any kind of verifiable identity of a person, machine control interface, or sensor. Identities are used to create multiple destinations cryptographically linked to that identity.
Transport Nodes forward data to a destination through a route determined by announces, which essentially tell every Transport Node the most efficient next hop for data sent to a specific destination. Destinations do not store any kind of map of the network as that would be incredibly inefficient.
When an announce for a destination is sent by a Peer, it will be automatically recorded and forwarded by any transport node, subject to some specific rules defined in the Reticulum manual that I will simplify:
The keys and path to a destination can be requested from any connected Transport Node if a destination does not already have an announce from the destination it is trying to reach.
There are more specifics about the routing, connection, and encryption processes in the Reticulum manual, but this should help you form a reasonable understanding of the concepts behind Reticulum's incredibly efficient routing strategy that allows Transport Nodes to directly pass data to a destination without needing to know the network's topology.
That being said, you might still want to know what connections Reticulum can work over.
The answer is basically anything, though there are some limits.
The reference implementation of Reticulum currently supports connections over any Ethernet, WiFi, KISS mode packet radio, or serial connection, as well I2P, TCP, and UDP. LoRa is also supported via RNode, a digital radio transceiver program designed for things like Reticulum, supporting many common LoRa boards.
Of course that doesn't mean Reticulum only supports these interfaces, currently any connection faster than 5 bits per second that can send packets 500 bytes or larger are supported, so that means basically anything you can imagine, as long as the work is put in to support it. There is even a very easily utilized generic "pipe" interface, that can use any external program as an interface so you can add new devices without even touching Reticulum code!
As long as two or more devices are somehow connected together, either directly or through devices with a Transport Node running, they can form a network. Remember that because of Announces, Reticulum is self-organizing and can form a network over any and all of these interfaces simultaneously. Once the interfaces are set up and the necessary destinations are set to be transports, you're basically done with any network configuration!
So that's great, but what's the point of a network stack that nothing makes use of yet?
This is why the Reticulum creators made LXMF, a Reticulum-native messaging protocol that allows for standard long and short form messaging functionality, communication between networked devices, paper messages, and offline reception of messages.
Offline messaging is facilitated by LXMF Propagation Nodes, which store and forward messages to Peers that are not directly reachable when a message is sent. LXMF Propagation Nodes can also provide infrastructure for distributed bulletin, news, or discussion boards.
Propagation Nodes will, by default, peer with each other and synchronize messages over time, automatically creating an encrypted, distributed message store. Users can retrieve their messages from any available Propagation Node.
Propagation Nodes are not required for LXMF to work, they simply serve to add optional functionality that many users will find very useful.
It is very important to remember that LXMF's Propagation Nodes are not the same as the Transport Nodes that provide Reticulum's core routing functionality.
Another project you may be familiar with is Meshtastic. It is often compared to Reticulum, even though they are quite different internally.
Unlike Reticulum, Meshtastic works almost exclusively over LoRa and relies on flood routing. Flood routing gets exponentially less and less efficient for each node that is added, so their current limit is around 32 nodes and likely won't increase by much any time soon.
Meshtastic's stack can run entirely on a microcontroller, while RNode currently requires a separate device like a Raspberry Pi Zero to handle routing. However this might not be the case soon, as a port of Reticulum to C++ is currently in development.
Meshtastic's encryption is optional (and only recently gained per-connection encryption) while Reticulum requires per-connection encryption and has forward secrecy, meaning that if a connection's key is compromised, no previous or future connections, even to the same destination, will be compromised. This means the only real way to completely break Reticulum's encryption is to compromise the sender or recipient directly.
Meshtastic is a great project, especially for hyper-mobile LoRa-only communication, and I respect what they're doing, even though I personally find the concepts behind Reticulum much more interesting.
Now that I've explained how Reticulum works, let's try it out!
There are three major LXMF clients currently available, NomadNet, Sideband, and Reticulum MeshChat.
NomadNet is a desktop Terminal-based option with some features such as website-esque pages; while Sideband is a GUI app for both desktop and Android which is somewhat easier to use and can send images and files in chats.
Reticulum MeshChat's goal is to be even easier to use than Sideband, while keeping most of both Sideband and NomadNet's features. It has a very nice interface and adds even more features like voice calling and voice messages, while still working over LoRa.
To install any of the clients, follow the instructions on their Github pages:
Reticulum MeshChat - https://github.com/liamcottle/reticulum-meshchat
Sideband - https://github.com/markqvist/Sideband
NomadNet - https://github.com/markqvist/nomadnet
Once you've picked a client and installed it, you will need to configure some interfaces so you can connect to a larger Reticulum network. In Sideband this is done through the "Connectivity" and "Hardware" pages, with NomadNet it is done through config files in the hidden .nomadnetwork and .reticulum folders in your home directory, and with Reticulum MeshChat it is done through the "Interfaces" page.
The easiest way to get connected to other people and try out Reticulum is to join the testnet, you can find more info about that at https://reticulum.network/connect.html
Remember that when changing any of these options, you must completely restart your client for changes to apply.
Both NomadNet and Sideband have integrated guides explaining how to access and use their specific features, and I highly recommend reading them to better understand how to use each one.
You may even discover some less obvious features like Sideband's situation tracking functionality that, if enabled, allows groups to be easily organized and located at a glance, and the Repository page, which allows for the Sideband app to be shared offline!
For NomadNet specifically, make sure to pay attention to the keyboard shortcuts bar at the bottom of the screen. Each panel has different shortcuts that allow for a ton of functionality that you might otherwise miss.
So that's pretty much it for Reticulum's basics. To learn more, I highly recommend taking a look through the Reticulum Manual and Michael Faragher's Reticulum Primer, checking out the resources on Unsigned.io, and chatting with the Reticulum community in the Discussions tab on GitHub and in the Matrix room.