Live data from Hacker News

Reticulum, a secure and anonymous mesh networking stack

github.com

71–80 of 99 posts

Re: Reticulum, a secure and anonymous mesh networking stack

#72
post #35

Earlier quoted context omitted.

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.

Re: Reticulum, a secure and anonymous mesh networking stack

#73
post #28

Earlier quoted context omitted.

So what mesh stuff do you recommend for the uninitiated?

In the LoRA/radio device sense, Meshtastic[1] is probably the easiest to get started with. It's the biggest player in the space, has devices that come pre-installed and configured, the most likely chance of making contact with someone else, etc. MeshCore[2] is the other major player. It's newer and tends to have been adopted by communities that have run into issues with large Meshtastic networks. If you meant PC-base…

My dream would be to have something like Yggdrasil[0] over some kind of mesh-based transport. Yggdrasil already does a good job with routing, it just needs a mesh-based transport IMO.

[0]: https://yggdrasil-network.github.io

Re: Reticulum, a secure and anonymous mesh networking stack

#74
post #19

How does this differ from meshtastic? Is meshtastic just more chat based and this is more generic?

meshtastic is chat and lora only. its protocol is super inefficient and unreliable, and only can handle a maximum of 7 hops across the mesh.

Give a try to Meshcore, their design has proven to be reliable in realworld use.

Re: Reticulum, a secure and anonymous mesh networking stack

#76
> The Old Way: "I trust this site because the browser says the lock icon is green".

> The Zen Way: "I trust this destination because I have verified its hash fingerprint out-of-band, and the math confirms the signature".

PGP already tried something along those lines. It did not see any adoption.

Problem with that approach is: UX is horrible. If someone technical like myself struggled to get it up and running correctly, what chance do less technical folk have?

If you want to build a really boutique environment for 3 guys to feel good about themselves, the Zen path is the right path.

If you want the public to adopt it, you need that green lock icon.

Re: Reticulum, a secure and anonymous mesh networking stack

#77

Reticulum is a production-ready full network stack. Cryptography and anonymity are first-class citizens there. It is transport-layer agnostic, not just tailored for LoRa. I like it, but is see two main problems that prevent the wide adaption, and they are related: 1. The library is written in Python. If you want to design phone apps, Linux server daemons in C, or embedded software (for example for the Lilygo T-Deck)…

Surprisingly, the Rust impl is Std only, so it doesn't solve 1

I took a deeper dive in Reticulum-rs. It is std. It implements 20% of Reticulum functionality. And it has 2 major protocol incompatibilities (like a different size for the MTU / Maximum Transfer Unit).

It looks like a quick vibe coded hack to implement a subset, tailored only for Beechat's own devices.

If someone would want to implement a full no_std Reticulum lib, they would need to start from scratch.

Re: Reticulum, a secure and anonymous mesh networking stack

#78

Earlier quoted context omitted.

Lora, especially on regulated bands that are the most used ones, is designed for very small, very infrequent messages. It isn't suited for real-time chat (nevermind secure) and so I think you can't really make it work while respecting transmission regulations. There are lora modules that work on the 2.4GHz ISM band but then you probably need to consider whether Bluetooth is not a simpler choice if range is not the no…

>It isn't suited for real-time chat (nevermind secure) It is encrypted on private channels and direct messages. >and so I think you can't really make it work while respecting transmission regulations. I don't know from where your information's are from, but for sure not from reality. Voice encryption/scramble on Amateur-Band's is not allowed, everything else is ok.

> Voice encryption/scramble on Amateur-Band's is not allowed, everything else is ok.

It seems like you're saying voice encryption is not permitted, but data encryption is? This is not true in the US. Any encoding used for the purpose of "obscuring meaning" is not permitted on amateur frequencies. Even using code phrases like "the eagle has landed" is arguably not allowed. There are some narrow exceptions for things like satellite control codes, but nothing that applies to hobby mesh nets.

Here is the relevant Part 97 rule: https://www.ecfr.gov/current/title-47/part-97#p-97.113(a)(4)

> No amateur station shall transmit: [...] messages encoded for the purpose of obscuring their meaning, except as otherwise provided herein; obscene or indecent words or language; or false or deceptive messages, signals or identification.

Re: Reticulum, a secure and anonymous mesh networking stack

#79
post #32

Surprised to see nobody mentioned Yggdrasil [0]. It's a routing protocol with cryptographic, non-topologic addresses, which could be used on top of TCP/IP or any alternative stack, like LoRA. 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? [0] https://yggdrasil-network.github.io/

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.

Re: Reticulum, a secure and anonymous mesh networking stack

#80
post #32

Surprised to see nobody mentioned Yggdrasil [0]. It's a routing protocol with cryptographic, non-topologic addresses, which could be used on top of TCP/IP or any alternative stack, like LoRA. 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? [0] https://yggdrasil-network.github.io/

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.

Post reply on HN