Yggdrasil is great. It's high-performance, uses regular IPv6 TCP/UDP, and automatically forms one big, open network, where routes are available.

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.

This is something a clueless TV marketer would say, I suppose.

Both tools can be used to both build private networks managed by a single entity, and to connect to global shared volunteer-run network.

Reticulum is not a general purpose protocol-agnostic data transfer network into which you can plug anything. Also, when you want any kind of serious bandwidth over long distance radio, you have to meet with agencies managing national frequency plans, and they won't lease you anything for free.

Yggdrasil is hardly an “alternative to Internet” as long as it runs on top of Internet links. Moreover, when public Yggdrasil network becomes big enough (assuming that it still runs on volunteer public nodes, just many more of them), the core of the network will have to form a backbone with links shaped by user concentration and user traffic flows, just like network of physical cables used by providers is shaped by demand, concentration of computing resources, geographical features, and so on. Someone will probably have to collect funds to pay for that. Or some new smart multipath routing with dynamic load balancing will be invented.

Yggdrasil can peer over the internet, but that's just convenience. In a global internet blackout, you obviously wouldn't have a global Yggdrasil network in a week, month or year, but you can have a reasonable regional network in that time. Every user is a node and can expand the network to new people. It's a P2P mesh, not volunteer-run. As regional networks start to peer to each other, it forms one big network automatically. You need cables and hardware, but that's not a problem when everyone has the incentive of wanting to use it.

You could build a public network over Reticulum, but why deal with the inconveniences of the protocol just to run it over high-bandwidth? It's specifically optimized for very low-bandwidth transports, so that you can cover long distances with just a small group of participants.

It is very stable. I have been using it for several years for exactly this purpose without any problems. It simply runs in the background and does its job so reliably that I simply forget about it for long periods of time.

For starters, Reticulum can communicate over a Yggdrasil network natively, but no one has yet implemented a Yggdrasil link over Reticulum as far as I am aware.

A Yggdrasil link is an IP tunnel. Reticulum has its own network protocol instead of IP because IP would not work well over slow and low-bandwidth connections. I think tunneling IP through Reticulum would cause only headaches.

A few years back, I ran Yggdrasil (poorly) over LoRa using a then-available experimental Meshtastic IP tunnel. Reticulum supports text-only websites (in the NomadNet software), and I have tested how these load over LoRa links. Loading time on a single hop (lab conditions) isn't half bad, honestly. My point in telling you this is that much of the mesh networking space is proof of concepts and poor executions, which often must happen first before elegant solutions to real problems can form.

My 2¢ on why Meshtastic is so popular (despite its many flaws) is because the original developer decided to implement a solution for a real use case.

I currently use Headscale, can you give some more details on how you use this to the same effect as Tailscale / Headscale?

Yggdrasil is a more generic overlay. It can run over unconfigured Ethernet links, auto-discover other nodes on your local network, or punch through firewalls if you configure any public peers. You can setup a private network by only declaring your private peers. I think each device gets an entire subnet, so you might be able to expose multiple services on multiple IPs, though I'm not sure about that.

My use-case was sharing things like game servers and websites with friends—which we previously did by sharing each other's machines/servers via Tailscale—and accessing my homelab remotely. For the first case, the public Yggdrasil network was much better than a mesh VPN like Tailscale: I don't have to manage invites or accounts—everyone who knows the address can just connect.

For the second case, assuming addresses are discoverable (since 128 bits would make them quite hard to enumerate), I think a firewall gating by incoming IP will take care of that (since your IP is just a hash of your public key), though for now I've kept most sensitive ports unbound from it. I hadn't yet tried anything like Tailscale bridging (exposing a LAN address without configuring the client on the endpoint), but I'll try once I have a bit more free time.

Tailscale is a nice abstraction on Wireguard, but Yggdrasil feels less like a solution to your specific infra problems and more like a coherent vision of how the internet ought to be. You can just rely on IPs as identities, link-layer encryption with Noise Protocol, and out-of-box hole punching, with relatively low latency (though I haven't tested the speed). It's the same feeling of awe as when I first saw how easy it is to host Onion Services, only not hampered by the abysmal speeds.

ygdrasill is very very big! reticulum use small band ygdrasil cant work on this small radio network

Those are different weight classes. If I recall correctly...

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.