For the most up to date information on Reticulum, please see the Reticulum website at, or the Reticulum GitHub repository.

Reticulum is the cryptography-based networking stack for wide-area networks built on readily available hardware. It can operate well both on fast links, and on links with very high latency and extremely low bandwidth. With Reticulum you can build wide-area networks with off-the-shelf tools. It offers end-to-end encryption, initiator anonymity, autoconfiguring cryptographically backed multi-hop transport, efficient addressing, unforgeable packet acknowledgements and much more.

No kernel modules or drivers are required. Reticulum runs completely in userland, and can run on any system that runs Python 3.

Reticulum is very well suited to built secure, versatile and advanced networked applications that can run even in extremely resource-limited situations. This includes hardware such as 1200-baud packet modems (OpenModem, for example), data radios, LoRa-based radios (RNode, for example), or even ad-hoc WiFi or ethernet networks.

Reticulum is a complete networking stack, and does not use IP or higher layers, although it is easy to utilise IP (with TCP or UDP) as the underlying carrier for Reticulum. It is therefore trivial to tunnel Reticulum over the Internet or private IP networks. Reticulum is built directly on cryptographic principles, allowing resilience and stable functionality in open and trustless networks.

Networks For The People

The primary motivation for designing and implementing Reticulum has been the current lack of reliable, functional and secure minimal-infrastructure modes of digital communication. It is my belief that it is highly desirable to create a cheap and reliable way to set up a wide-range digital communication network that can securely allow exchange of information between people and machines, with no central point of authority, control, censorship or barrier to entry.

Almost all of the various networking systems in use today share a common limitation, namely that they require large amounts of coordination and trust to work, and to join the networks you need approval of gatekeepers in control. This need for coordination and trust inevitably leads to an environment of central control, where it’s very easy for infrastructure operators or governments to control or alter traffic, and censor or persecute unwanted actors.

Reticulum aims to require as little coordination and trust as possible. In fact, the only “coordination” required is to know the characteristics of physical medium carrying Reticulum traffic.

Since Reticulum is completely medium agnostic, this could be whatever is best suited to the situation. In some cases, this might be 1200 baud packet radio links over VHF frequencies, in other cases it might be a microwave network using off-the-shelf radios.

Further Reading

For much more information, please have a look at the Reticulum Manual.

For quick installation instructions and source code, the Reticulum repository on GitHub and the PyPi page are the places to go.

If you want to have a look at a program written with Reticulum, see Nomad Network or Sideband.

27 thoughts on “Reticulum Network Stack

  1. Hi I saw your yt video and the repo looking good..have you done any distance tests? for 9600 baud?

    1. Hi Kerry! The videos on my youtube page are very old, hope to get some new ones up soon with info on Reticulum. Just wanted to say that the current version of the modem and software is a bit nicer than what is in those old videos 😉
      I’ve been running quite a few tests over 1200 baud with a couple of MicroModems attached to Yaesu radios. Been doing file transfer over 30 kilometers distance from base station to a moving vehicle at highway speed and it performed great 🙂 I don’t have any legacy 9600 baud TNCs to test with, but there’s nothing stopping that from working. I’ll be running some tests with Direwolf TNC in 9600 baud mode soon.
      I’ve also done a bit of testing with the prototypes of RNode (a LoRa based packet radio, it’ll be available here very soon). RNode has data rates from about 1000 bps to 37.5 kbps, and works great with Reticulum as well.
      If you’re interested in the project I hope you will keep an eye on the blog and the repo, and please ask any questions that comes to mind, I will be more than happy to discuss!

    1. Ah well, as you might be able to infer from the calendar, that date has come and passed. I thought I had updated this page with a more realistic estimate, but apparently not, so thanks for the reminder.
      This being more or less a one-man show means a limited amount of resources, and I had to prioritise other projects first, namely RNode and it’s software.

  2. I’ve got some APRS projects I”m working on with your excellent aprslib and micro_modem designs. Once I get my head a little better around the inner working of the APRS network I’ll have to look into this. Any change it will be/can be/already is made workable with micropython? I’d love to plug this into an ESP8266 or something similar.

    1. Yes, the plan is to make it micropython compatible. Almost everything is already, but a few external dependencies are not supported on micropython by default, and I’ll be working on porting those over. Right now though, I’m putting the finishing touches on my new hardware project OpenModem, so I won’t make much progress on this before OpenModem is released.

  3. Wondering what can I do to help and if their is a update on Reticulum? Also in the paper it is not clear how you plan to switch frequency (lora to 1200) can you explain more?

    1. I’d very much appreciate help, especially if you are good with Python or other core aspects of the project. Lately I’ve had to put Reticulum on pause, because of life intervening. I’ve moved both my home and my entire workshop and business, which has taken up lots of time and resources, so I needed to focus on the work that pays the bills 😉 I’ll probably be able to return more or less full time to finishing Reticulum before the end of the year, and when the first reference implementation is done, and I have finalised the specification for the protocol, it’ll be much easier to use, test and develop further. I hope you will have just a little more patience with me 🙂
      Currently Reticulum supports multiple mediums like LoRa and 1200-baud AFSK at the same time, or individually. You can easily make a network that cross-connects the two different modulations, simply by adding a LoRa interface and an 1200-baud interface to the same Reticulum node. The internal routing stack will automatically transport packets from one medium to another if needed.

      1. Would definitely like to help. Something of this sort is not yet done (no tcp/ip). We need to get more people involved and have a direct plan (solving certain situations). What can we do to help? Also I do think that their is place for servers that can transmit longer distances and store messages of a user is not present this can be optional but does provide more of a backbone.

  4. Hi, this is a great project. Do you think it would be possible to eventually support Android/iOS? Or do these platforms make it impossible to configure the Wi-Fi for such purposes? Could it be accomplished on the new Linux phones (Pinephone, Librem 5)? Thank you.

    1. Yes, Android and iOS support is something that I am aiming for down the line. Whether it will be possible to use a mobile devices internal WiFi radio will probably be quite device-dependent. As far as I know it’s currently not possible on iOS, but on some Android devices it is. Although I have not yet had the pleasure of tinkering with any of the new Linux phones yet, I’d be willing to bet that it’s much easier on those. A shame it’ll probably be a while before we have a phone with full access to the baseband chips 😉

      But, realistically speaking, the first way it will be possible to use Reticulum on mobile devices will probably be by using an external radio (RNode for example) connected to the phone over bluetooth, or by having a Reticulum node on your local network that the phone app just transports packets through.

      As an example, I currently have a Reticulum node set up that is connected to both my local network, a LoRa interface and a VHF packet radio interface. This means that any device on the network can also communicate over LoRa and VHF packet, since Reticulum will transparently transport data over the correct interfaces, and conversely, I can reach Reticulum peers on my local network from afar using VHF.

  5. Hi Mark. First of all, I’m in love with RNS and the associated hardware interfaces you have developed, and I’m really excited about all of it. Now on to my question 🙂

    I have a RNS instance running on a couple RaspberryPi’s (it’s so easy to get up and running!), and I am able to setup a link (thank you for including some examples). I will try to lay out my situation below.

    Node A: create a RNS.Destination using a known destination hash, and call RNS.Transport.requestPath()
    Node B: responds to path request
    Node A: Request a RNS.Link to Node B
    Node B: Accept and prove link with Node A

    So the link is established, and I am able to send messages. However, looking at the link attributes on both ends:

    Node A: Link.owner = Node A hash, Link.destination = Node B hash (this looks ok)
    Node B: Link.owner = Node B hash, Link.destination = Node B hash (who called??)

    How does Node B know who the link request came from if Link.owner and Link.destination refer to itself? I read through your Reticulum Overview again, and the line ‘Only the intended destination will know “who called”, so to speak.’ made me think that Node B’s Link.destination should be the hash for Node A, so it knows who the link is associated with.

    It looks like RNS.Link.validateRequest() is explicitly setting the link destination to the link request packet destination (which would be the node receiving the request, instead of the node sending the request), which would make sense with what I’m seeing for the node receiving the link request (Node B in this example). However, it looks to me like the RNS.Link constructor (when self.initiator is True) is only setting self.request_data to the link public key (Lk), which doesn’t seem to align with the description of the content of the link request packet from the Overview document: “The link request packet contains the destination hash Hd, and an asymmetrically encrypted part containing the following data: The source hash Hs, a symmetric key Lk, a truncated hash of a random number Hr, and a signature S of the plaintext values of Hd, Hs, Lk and Hr.”. Which would mean the information about who is requesting the link isn’t being included in the link request packet in the first place. Let me know if I’m off-base here, and there is another explanation.

    Keep up the great work with all of this! I love the vision, and I’m very excited about implementing a network with RNS, RNode, and now OpenModem!

    1. Hi Howard

      Yes, that is not very clearly written. I guess the overview document could really do with an update in some areas. Thanks for pointing it out! Since writing that, I actually changed the underlying mechanisms of link establishment to achieve some things that were not possible in the first implementation.

      First, I moved the link encryption to much more efficient and stronger ephemeral Elliptic Curve DH scheme, which also provides forward secrecy. Second, I wanted link establishment to be possible with initiator anonymity, so any node can establish a link to a destination without _having_ to identify or reveal it’s own identity or location in the network.

      It should still be _possible_ to identify though, but I haven’t yet sat down and thought it through completely how that will be best implemented. If it’s an important feature to you though, I’d be happy to move that up the list of priorities, since it’s going to be relatively simple implementation-wise. It’s more a case of having to get it right from the get start 😉

      The third reason is that the current implementation is much better suited to the delay tolerance features that I’m currently working on. When these are implemented, Reticulum will support DTN modes for both single packets, links and resource transfers, which means you will be able to ask the network to handle a transfer reliably for you, even if some intermediate hops are temporarily offline. Data will be able to “queue” up so to speak, and move along when suitable hops become available, or find alternative paths.

      The destination you are seeing is actually the link id. It’s a hash of link request packet. When the link has been established, it becomes the “destination” that either node refers to to pass data to it’s remote end.

      I’ll update the overview document soon, it’s very much due for a revision, since a lot have happened since the last one.

      Thank you so much for your encouraging words! I am very pleased to hear that you enjoy experimenting with Reticulum! Please just write me a mail if you have any questions or other matters you wish to discuss.

      Kind regards,

    1. Yes, and I intend to do so once the Python implementation is complete 🙂

    1. Yes, it is. If one path through the network disappears, another one can take it’s place dynamically. The speed at which this happens could be improved though, and I’m planning on implementing a “search” operation, sort of a “reverse announce”, that can remap transport tables on-demand, if a node detects that the expected path has disappeared.

  6. Thank you for answering my previous question, Mark.

    I’d like to ask a few more things if you don’t mind. First, how does Reticulum compare to other open-source non-IP routing projects? The only one that comes to mind right now is BATMAN; the most glaring differences would be that it uses MAC addressing and non-encrypted communication. Beside that, how does Reticulum differ from BATMAN (and any others if there are), regarding scalability, topology, latency, overheads, simplicity, overall design…? (I prefer Reticulum much more, but I’d like your take nevertheless.)

    Also, do you think that Reticulum could ever support high-bandwidth low-latency communication, or is there anything in its design that will prevent this use case in the future (even for small networks)? Would it be just a matter of using high-end devices? And how much can Reticulum scale (how many nodes can it support)?

    Thanks again for your time, hope the project is going well. Cheers!

    1. Yes. The full API documentation and protocol-stable beta is very near release. And some actual real-world software built on Reticulum 🙂 Stay tuned.

  7. I wanted to understand one thing clearly. Can we implement a mesh in LoRA. Meaning, star topology or series connection meaning, Device A is connected to B, B is connected to device B and C, C is connected to D and B. But eventually they can all talk to eachother.

    1. Yes, more or less any network topology is possible to configure with Reticulum.

  8. Any progress towards porting to the ESP32 yet? I read your previous answers to that question, and wondered if there is an update?

    1. I take it that you mean running RNS natively on ESP32, and not just using ESP32 devices as interfaces, right? In case of the latter, there is already support for ESP32 in the RNode firmware.

      In case of the former, then yes, there is actually quite a bit of progress, but it is not the highest priority right now, and nothing is released publicly yet.

  9. If you’re running SSH over RNS, can it be used for AX.25? Would it be possible to integrate an Rnode with a DigiPi? Could you use this as a APRS gateway between networks?

    1. The SSH experiments you can find on my site did not use RNS, but simply used the RNodes as plain network cards on Linux.

      You can use RNodes for AX.25 stuff no problem, they will act completely as a plain old TNC, when put into TNC mode. And yes, in the same vein, you can also use them with DigiPi and for APRS stuff.

Leave a Reply

Your email address will not be published. Required fields are marked *