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 truly global scale peer-to-peer mesh networking I've seen.
Reticulum has potential to become a legitimate replacement for the internet, and it is versatile enough to work over almost any networking medium including LoRa, serial, and packet radio. It's a full network stack down to the physical layer, everything is end to end encrypted per packet, and it's also surprisingly efficient.
With Reticulum, anyone can make and join self-organizing and almost completely unmanaged networks that can freely interconnect, and are very difficult to take down, surveil, or censor. Of course Reticulum is still in development, but it already works astonishingly well.
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; how exactly does Reticulum work?
Let's start with establishing some basic terminology.
RNS (or Reticulum Network Stack) is the reference implementation of the Reticulum protocol, written in Python.
Destinations are essentially 'endpoints' that allow for programs to receive data. They are more of a routing concept than a reference to a specific program or device, and a single physical device can host multiple different destinations. There are a few types of destinations:
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 to destinations.
A Node is an instance of Reticulum. There is generally one per device, and a 'Shared Instance' is created to allow multiple programs to connect at once.
A Transport Node is an otherwise standard node that is set to route data via a single configuration option. Not all nodes route traffic because this wastes bandwidth and descreases the reliability of larger networks just to support Transport Nodes that will never route anything. Reticulum can technically work without Transport Nodes, but only directly connected nodes are able to communicate without them.
Nodes do not know anything about a 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 make a destination reachable, a program simply needs to send an announce on any network it is connected to.
An Interface is a connection over any medium between two or more nodes.
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 program, 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 node 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 these basics 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 nodes are set to be transports, you're basically done with any network configuration!
Interfaces also have special announce propagation rules that can be enabled, known as Interface Modes, allowing for more advanced network configuration and helping mitigate edge cases.
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 message format that enables 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 nodes 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 essentially sends every single packet to every single node, making the network exponentially less and less efficient as more nodes are added and more messages are sent. In normal use, this means that it takes relatively few nodes sending data to completely overwhelm an entire network. To mitigate this, Meshtastic has a maximum hop limit of around 7 hops (with 3 hops being "strongly recommended") while Reticulum supports 128 hops.
Meshtastic's stack can run entirely on a microcontroller, while standard RNodes require a separate device like a Raspberry Pi Zero to handle routing. There is, however, a port of Reticulum to C++ that can run entirely on a microcontroller, called microReticulum, which is already in a relatively usable state.
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 that, at least theoretically, the only feasible 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.