Reticulum, a secure and anonymous mesh networking stack

Further, "Occasional updates may appear at unpredictable intervals, but there will be no support, no responses to issues, no discussions, and no community management in this or any other public venue."

Nothing salacious here - just another one man open source project with a burnt out maintainer :(.

[1] - https://github.com/markqvist/Reticulum/discussions/1069

> To the small group of people who has actually been here, and understood what this work was and what it cost - you already know where to find me if it actually matters.

>To everyone else: This is where we part ways. No hard feelings. It's just time.

https://github.com/markqvist/Reticulum/blob/master/MIRROR.md

Bigger than.. what?

> One of the main reasons of the communities not jumping onto the ship was that it's mostly a one-man-pr...

Reticulum does not support group chats. Which is a far more realistic explanation than suggesting the average user cares what the commit messages are.

Reticulum enables the creation of many different smaller networks, optimized for high-latency, low-bandwidth links (LoRa, packet radio). It uses its own addressing and transport system, with applications which are specifically made and optimized for it.

Both are mesh networks, but have different use cases. Want to build your own private data network over longer distances? Reticulum. Want a fast alternative to the internet that's far more decentralized and secure? Yggdrasil.

Reticulum is a protocol and a set of ideas about basic building blocks for data exchange.

Let's say you have some rusty wet wires (a serial link) or an antenna. You need to send some data. Typically, it goes like that: “Well, 0x01 is HELLO command, 0x02 is BYE... No, 0xFF is BYE... No, 0xFF should be reserved escape code for two byte commands”, and so on. Then you realise (or find out) that someone else might accidentally or deliberately send similar messages, and their correctness and validity should be checked. You add hard-coded encryption keys (because surely no one is going to look for them), re-invent key exchange protocols, then wrap everything in TLS because it's the only thing that is expected to work globally (usually with hard-coded soon-to-be-expired certificates or without certificate checks at all). If you use some standard bus, some of those things have already been offered to you.

Reticulum message payload is signed and encrypted by default (except for local broadcasts, but clear text can be treated as encrypted with a key everyone knows). Its destination is an abstract identity (tied to a pair of asymmetric cryptographic keys) which does not correspond to any physical network. They all are simply assumed existing and unique in some global space. No assumptions about protocols are made. You get some lower level data pipes — shared medium (radio, bus — the difference is in the shape electromagnetic waves take anyway), real or virtual point-to-point links (e.g. over IP). You can announce your presence, that's Layer 0 packets. You might not, and only listen passively. You can exchange some routing data and other gossip with peer nodes. That's also Layer 0 packets. You run some application, and destination it creates for is no different from node destination, and its announcements are no different from node announcements, and they are also Layer 0 packets. One application on one node sends data to another, on another node? Same Layer 0 packets to some abstract identity. If you imagine a graph of node-identities, application-identities are also there, on the same plane, directly peering to their nodes. Same for multiple service-identities or user-identities under the hood of one application.

Obviously, some kind of smart routing should support such identity graphs. First of all, we start with no routing, that's why one of the examples in the documentation is a temperature sensor that simply sends packets to a pre-defined identity over radio. It does not care whether the rest of the network exists, or whether anyone is listening to it. It might be a single board computer on the other side of the room, the only other node in the local network, with that destination as a sink for temperature data. It might be the same device with a globally-connected node that relays those messages, and over multiple hops over various types of links it gets to the destination at the other side of the world. The sender sees no difference.

Then we have announcements that are re-broadcasted to peers of peers (if they have available announce bandwidth). As a result, nodes in the network (or some part of it) grow a list of routes based on how fast they got that announcement, from which peer, and with which retransmit (TTL) value (to reach destination abcd..., send packets to peer P). It is understood that those events are “rare enough”, and the backbone “transport nodes” should be “stable enough”. It is totally relative, though: default announcement rate might be on each restart or once a day, to accommodate for long range low bandwidth radio links, but on fast fat frequently changing local networks you can choose to re-announce each second, just like with routers checking each other via STP. On the other hand, we might not what to announce ourselves to the whole world (“Name's Bond, James Bond, destination 007...”), or someone might connect to the network after the announcement. There's an option to send WHO-HAS message from the other side if there is no known path to the destination yet. Without deliberate announcement, only the direct peer (our local node in case of some application destination) will know that we are present.

Basic communication is unidirectional, and each message is independent from the other. You don't know whether someone received your message until the other side decides to send you the confirmation (if it knows where to send it using data provided inside the message or external knowledge). If two people meet, write down each other's destinations, and agree when to be online to use some application just sending individual packets, they don't need any high level protocol. Otherwise, there is the same freedom to adapt as in routing. One option is to establish a bidirectional link between two online destinations. It is a higher level abstraction provided to manage stable virtual circuit along multiple hops, disassembly of data into packets and correct assembly of them, one-time session keys for forward secrecy, and so on. Other option, supported in LXMF, is to store and fetch the data with the help of an intermediate participant. Obviously, store and fetch might happen at different points in time, so intermittently connected participants might choose to use that. At the moment, those intermediates (“propagation nodes”) are simply chosen from random volunteers, but the system can be extended to provide fault tolerance and load distribution with common methods at higher level.

There is built-in anonymity option (obviously, not “complete anonymity”, just anonymity among Reticulum network users). If Alice and Bob want to chat in presence of some adversarial nodes matching opaque traffic, they can do that. However, if Alice or Bob is secretly working with those spying nodes, it's a bit different story. That's probably not that important with current number of users.

So even if Reticulum can transfer IP packets as payload, and theoretically be used as a general purpose IP overlay network, it makes little sense. It is also, most likely, not optimised at all for that specific task.

Yggdrasil is quite different. It's a practical test of an implementation of universally scaling routing algorithm (a number of such algorithms, if we take previous versions into account). It uses common IP transport, and therefore is aimed at systems with complete network stacks. Its goal is not being a cool mesh virtual private network (though it is cool), but to prove that decentralised global network with random user-generated cryptographic identities can converge and efficiently route traffic all by itself. But, yeah, all the cool kids these days have the [2xx:/[3xx: addresses, and even mine vanity ones.

- On 32-bit x86 platforms it has to build the PyCA/cryptography module, but works fine after it does that.

- Reticulum supports a number physical interfaces, serial is one of them. It of course has the "RNode" intefaces for LoRa radios. For Ethernet, there is "AutoInterface" which uses IPv6 autoconfiguration for peer discovery and IPv6 UDP for transport but doesn't rely on DNS, DHCP, or anything else. If your PC, phone, or other involved devices on the same network have IPv6 enabled and no filtering is happening on layer 2 then it's dead simple - any device there will see announces from others and be able to transact with you not doing much more than spinning up MeshChat.

- Other interface types are TCP client, TCP server, IPv4 UDP, I2P, and a pipe interface. The pipe interface is interesting as it's basically stdin/stdout to an executable of your choice, so you can use that to make Reticulum available over really anything you could dream up, such as an SSH tunnel.

Meshtastic and Meshcore are mesh messengers, focusing on mesh text messages.

Reticulum requires you to manually define your uplinks, including remote servers. If this remote server is blackholing your traffic, you are SOL.

If you define multiple remote servers, then you may be in luck iff your destination is advertising its route on a path (chain of servers) that has no such hostile nodes.

Remember that Fido and Usenet relied on independent server admins voluntary enforcing the rules for global groups (and allowed the alternative sister hierarchies or local appendices with different rules). It is possible to give more power to local decision maker, and share the global ideas.

Link establishment mentions validation of the circle by the intermediate hops. I suppose that someone who is sending a lot of packets without participation from the other side can be put into exponentially worse and worse queues. Or maybe not. There's a lot of things to test.

reticulum itself describes the network stack (like tcp/ip) and it has its own protocols like LXMF for messaging and LXST for streaming. applications can be built on top of these protocols.

it’s different than IP, instead of addresses, each node has an identity that’s a cryptographic key pair that you send messages to, the routing happens in the background regardless of network topology or diversity of link types.

you CAN send reticulum packets over a TCP/IP adapter and thus across the normal Internet (there are a lot of testnet and community nodes that are accessed this way), but the protocol also seamlessly bridges over any interface (lora, bluetooth, HAM radio, etc) that is attached to the node.

so like, there could be a message sent over lora to a base station that relays it to another server through the internet, then that server sends it out over a ham radio link to another computer somewhere else, etc.

all the message sender has to know is the pubkey of the node they want to talk to, and the network figures out how to establish a link.

128 hops maximum.

the prerolled binaries of the aforementioned software include the network stack and easy enough presets to find content from other nodes and people to talk to.