you can already send photos and voice chat over lora, and when lora runs out of bandwidth or if there’s no link, the protocol can seamlessly go over any other link type.
I just happened to recently learn about Reticulum from another part of the internet and find it fascinating. Am I correct in thinking that it can basically run on anything that can run arbitrary code and the ability to talk to another device? (seems like it'd even work over serial if one had the determination to make it work)
The Software shall not be used, directly or indirectly, in the creation of an artificial intelligence, machine learning or language model training dataset, including but not limited to any use that contributes to the training or development of such a model or algorithm.
Looks great. Does it need all users to install Reticulum, or app/service prividers (online shop etc) on Reticulum can make their services available for access via browsers?
This is cool, I’ve been playing around Offline Protocol’s DORS SDK that they put out last month and it’s been great for cross platform whereas Bitchat’s Noise setup was a little more cumbersome to get started. Need to dig more into LoRa meshes.
I've never seen a bigger network with Reticulum in the wild. And I'm deep into Mesh stuff with several local communities.
One of the main reasons of the communities not jumping onto the ship was that it's mostly a one-man-project and most of its Git changes are "Update" "Better Version" "Update" "Cleanup" which makes it basically impossible to track changes.
> 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.
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.
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.
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.
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 sen...
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) this is a bad choice. Somehow doable (execpt for embedded), but no fun. A small lib with C API and C ABI would be better.
2. Most of the end user software has a horrible UI. But it gets better with software like the Android messenger Columba (https://github.com/torlando-tech/columba).
If we would solve 1., we would have more end user software.
Currently, there are 4 project who try to solve 1. by writing a Reticulum lib with a low-level language, everybody does it in their favorite language and on their own, of course: C++, Zig, Rust, Go
The Rust implementation from Beechat seems the most mature. But I did not see it used in the wild, outside of Beechat's own devices.
Practically, my biggest concern is deliver ability
> The Zen Way: "I am <327c1b2f87c9353e01769b01090b18f2>. Wherever I am, my peers can reach me".
> When links are intermittent and latency is measured in minutes or hours, "real-time" is an illusion. Reticulum doesn't encourage Store and Forward as a mere fallback, but as a primary mode of existence. You write a message, it propagates when it can, and it arrives when it arrives.
Let's say A and B are talking.
A sends message A1.
B receives message A1.
B sends message B1.
A receives message B1.
A sends message A2.
Something happens and B doesn't receive it.
A sends A3.
B receives A3.
Later, B receives A2.
Now what does B do with this information? Does the envelope contain all the metadata about when A sent it so B client software can order the messages properly?
Here is what I'm confused about: There is no published protocol/spec. It's nominally for radios like LoRa (Semtech) which are programmed with microcontrollers. To run it, you need Python software, or more recently, std Rust, both of which can't be used on the devices that would make sense for the hardware.
> 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.
With current size of the network, it's probably managed by sending messages to operators chat “Hey, IP a.b.c.d is doing that again”.
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.
33 comments
[ 3.5 ms ] story [ 51.7 ms ] threadto get started easily, check out meshchat:
https://github.com/liamcottle/reticulum-meshchat
or sideband on android:
https://github.com/markqvist/Sideband
you can already send photos and voice chat over lora, and when lora runs out of bandwidth or if there’s no link, the protocol can seamlessly go over any other link type.
One of the main reasons of the communities not jumping onto the ship was that it's mostly a one-man-project and most of its Git changes are "Update" "Better Version" "Update" "Cleanup" which makes it basically impossible to track changes.
> 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.
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/
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 sen...
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) this is a bad choice. Somehow doable (execpt for embedded), but no fun. A small lib with C API and C ABI would be better.
2. Most of the end user software has a horrible UI. But it gets better with software like the Android messenger Columba (https://github.com/torlando-tech/columba).
If we would solve 1., we would have more end user software.
Currently, there are 4 project who try to solve 1. by writing a Reticulum lib with a low-level language, everybody does it in their favorite language and on their own, of course: C++, Zig, Rust, Go
The Rust implementation from Beechat seems the most mature. But I did not see it used in the wild, outside of Beechat's own devices.
> The Zen Way: "I am <327c1b2f87c9353e01769b01090b18f2>. Wherever I am, my peers can reach me".
> When links are intermittent and latency is measured in minutes or hours, "real-time" is an illusion. Reticulum doesn't encourage Store and Forward as a mere fallback, but as a primary mode of existence. You write a message, it propagates when it can, and it arrives when it arrives.
Let's say A and B are talking.
A sends message A1.
B receives message A1.
B sends message B1.
A receives message B1.
A sends message A2.
Something happens and B doesn't receive it.
A sends A3.
B receives A3.
Later, B receives A2.
Now what does B do with this information? Does the envelope contain all the metadata about when A sent it so B client software can order the messages properly?
> 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.
As far as I know, most mesh routing protocols is very sensitive to rogue nodes, even if it is misconfiguration and not malicious intent...
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.