I've been using it as a Tailscale replacement for a few weeks, including hosting game servers, with about equivalent latency, and it seemed pretty stable.
How does Reticulum differ?
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.
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.
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.
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.
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.
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.