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

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.