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.
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.
And, as of 3 weeks ago, the one man is "stepping back from all public-facing interaction with this project".[1]
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 :(.
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-based mesh networking, I'll leave someone more knowledgeable to speak about that :).
I've had some experience with both Meshtastic and Reticulum, and Meshtastic software was mostly unusable for me even with 3-node networks. E.g. a node sends a message and gets a successful delivery notification from the receiver but the receiver fails to display the message to the user. Reticulum was mostly working fine. Haven't tried MeshCore yet.
Meshtastic also doesn't really... work. Let me qualify that. You can get a couple of nodes for cheap, and you can (with a bit of work) get messages to go between them. The problem is coordination between nodes is required for the network as a whole to work. Specifically, user adjustable node -local settings can overwhelm the network for everyone else around you. Defcon "solves" this by providing firmware to flash with preconfigured settings tuned for the event. But hopefully this makes the problem obvious - in some other scenario that you might hope to use them - and TBC, my goals for a long range, non-cellular network mesh network are for connectivity during a hurricane/flood/firestorm/earthquake/tornado/etc.
An open implementation is preferred, because it drives down the cost of hardware and lets users purchase the grade of hardware they want. But if it doesn't work, an imperfect proprietary solution(s) available now > hypothetical perfect future solution.
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. 1 concern.
>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.
I know what features it claims to have. The question is how well this can work on bands (US915, EU868) that very strictly limit the amount of time a device may transmit. IMHO you can't really have interactive chat on a mesh network over lora in those bands.
>IMHO you can't really have interactive chat on a mesh network over lora in those bands.
Devices allow 10% Airtime on ISM here (EU) that's about 300 messages (with 255 characters) per hour, and yes interactive chat is possible with around 20 seconds of lag.
EDIT: I stop here, so much half knowledge that sounds educated but is in fact just wrong and TBH not even sure if i talk to a selfhosted AI.
Yes, in the EU one subband allows 10%, the rest is 1%. I believe that Meshtastic uses that whole 250kHz of that subband by default. This is by far the most relaxed constraints of what is available in the EU and US. That's about 180 max. size messages per hour (at longfast) per device but you need to take into account retransmissions, acks, mesh management and routing of third party messages. So it may work, barely, for this specific config and very small number of people or 1-to-1, but that's it.
I am not picking on Meshtastic specifically, it's just that Lora and, especially the regs on those bands are such that some applications are never going to work well beyond extremely small meshes, if at all.
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.
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.
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)
- If it runs Python and pip/pipx, and you can pull in the required packages via pip/pipx, it'll run Reticulum.
- On 32-bit x86 platforms it has to build the PyCA/cryptography module, but works fine after it does that.
- Reticulum supports a number physical interfaces, serial is one of them. It of course has the "RNode" intefaces for LoRa radios. For Ethernet, there is "AutoInterface" which uses IPv6 autoconfiguration for peer discovery and IPv6 UDP for transport but doesn't rely on DNS, DHCP, or anything else. If your PC, phone, or other involved devices on the same network have IPv6 enabled and no filtering is happening on layer 2 then it's dead simple - any device there will see announces from others and be able to transact with you not doing much more than spinning up MeshChat.
- Other interface types are TCP client, TCP server, IPv4 UDP, I2P, and a pipe interface. The pipe interface is interesting as it's basically stdin/stdout to an executable of your choice, so you can use that to make Reticulum available over really anything you could dream up, such as an SSH tunnel.
The only fully-functional stack currently available requires Python >= 3.8, which is the main limitation to where it will run. But there’s still a lot you can do with that!
Reticulum is a full network stack with full user anonymity.
You can integrate it in every app that needs P2P network connections and that can live with a slow connection.
Reticulum is an alternative to TCP/IP and UDP/IP, using a mesh.
Meshtastic and Meshcore are mesh messengers, focusing on mesh text messages.
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.
I saw this too and immediately thought: well, they published this on GitHub which surely has a clause that grants it a license to use the code for training Copilot for Microsoft at a minimum, sooo should've published on another Git platform.
> This repository is a public mirror. All development is happening elsewhere.
So if I have code on a personal (but publicly exposed) git server with a license that includes the above quoted terms, and someone decides they want to be helpful and publish a public read-only mirror of my code to GitHub, then they’re allowed to accept that license on my behalf? I never did a thing and yet I’m now in a contract with Microsoft? How does this work legally?
1. Microsoft does not gain the license, but will be able to argue that they aren't intentionally committing copyright infringement in the cases where that distinction matters.
2. If Microsoft does something resulting in damages because they thought they had a license, their indemnification clause kicks in and they can recoup those damages from the user who uploaded it (to the extent that that user doesn't go bankrupt anyways)
3. Likely none of this matters because your license can't prevent activities that weren't prohibited by copyright in the first place, and training doesn't appear to be a prohibited activity at least under US law.
When code is published on GitHub, GitHub itself is not bound by the public-facing license, but rather license grants the uploader aggress to as part of the terms of service. That points to the uploader as a responsible party.
In practice though, none of that is even remotely enforceable.
> You grant us and our legal successors the right to store, archive, parse, and display Your Content, and make incidental copies, as necessary to provide the Service, including improving the Service over time. This license includes the right to do things like [...] or otherwise analyze it on our servers; share it with other users
That could be boilerplate legalese for "obviously we need access to your code if we're to display and share it (as is the purpose for a public git host)"
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?
all users need to be running the reticulum network stack to be able to send, receive, and route packets.
reticulum itself describes the network stack (like tcp/ip) and it has its own protocols like LXMF for messaging and LXST for streaming. applications can be built on top of these protocols.
it’s different than IP, instead of addresses, each node has an identity that’s a cryptographic key pair that you send messages to, the routing happens in the background regardless of network topology or diversity of link types.
you CAN send reticulum packets over a TCP/IP adapter and thus across the normal Internet (there are a lot of testnet and community nodes that are accessed this way), but the protocol also seamlessly bridges over any interface (lora, bluetooth, HAM radio, etc) that is attached to the node.
so like, there could be a message sent over lora to a base station that relays it to another server through the internet, then that server sends it out over a ham radio link to another computer somewhere else, etc.
all the message sender has to know is the pubkey of the node they want to talk to, and the network figures out how to establish a link.
128 hops maximum.
the prerolled binaries of the aforementioned software include the network stack and easy enough presets to find content from other nodes and people to talk to.
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.
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.
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.
And, as of 3 weeks ago, the one man is "stepping back from all public-facing interaction with this project".[1]
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
it’s a bummer, but according to folks in the matrix chat, he’s still developing and in touch with some of the community devs.
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-based mesh networking, I'll leave someone more knowledgeable to speak about that :).
[1] - https://meshtastic.org/
[2] - https://meshcore.co.uk/
I've had some experience with both Meshtastic and Reticulum, and Meshtastic software was mostly unusable for me even with 3-node networks. E.g. a node sends a message and gets a successful delivery notification from the receiver but the receiver fails to display the message to the user. Reticulum was mostly working fine. Haven't tried MeshCore yet.
Meshtastic also doesn't really... work. Let me qualify that. You can get a couple of nodes for cheap, and you can (with a bit of work) get messages to go between them. The problem is coordination between nodes is required for the network as a whole to work. Specifically, user adjustable node -local settings can overwhelm the network for everyone else around you. Defcon "solves" this by providing firmware to flash with preconfigured settings tuned for the event. But hopefully this makes the problem obvious - in some other scenario that you might hope to use them - and TBC, my goals for a long range, non-cellular network mesh network are for connectivity during a hurricane/flood/firestorm/earthquake/tornado/etc.
An open implementation is preferred, because it drives down the cost of hardware and lets users purchase the grade of hardware they want. But if it doesn't work, an imperfect proprietary solution(s) available now > hypothetical perfect future solution.
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. 1 concern.
>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.
I know what features it claims to have. The question is how well this can work on bands (US915, EU868) that very strictly limit the amount of time a device may transmit. IMHO you can't really have interactive chat on a mesh network over lora in those bands.
>I know what features it claims to have.
Yeah...no i don't think so.
>IMHO you can't really have interactive chat on a mesh network over lora in those bands.
Devices allow 10% Airtime on ISM here (EU) that's about 300 messages (with 255 characters) per hour, and yes interactive chat is possible with around 20 seconds of lag.
EDIT: I stop here, so much half knowledge that sounds educated but is in fact just wrong and TBH not even sure if i talk to a selfhosted AI.
Have a good Day.
Yes, in the EU one subband allows 10%, the rest is 1%. I believe that Meshtastic uses that whole 250kHz of that subband by default. This is by far the most relaxed constraints of what is available in the EU and US. That's about 180 max. size messages per hour (at longfast) per device but you need to take into account retransmissions, acks, mesh management and routing of third party messages. So it may work, barely, for this specific config and very small number of people or 1-to-1, but that's it.
I am not picking on Meshtastic specifically, it's just that Lora and, especially the regs on those bands are such that some applications are never going to work well beyond extremely small meshes, if at all.
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/
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.
it hit version 1.0.0 this summer and it works!
to 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.
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)
- If it runs Python and pip/pipx, and you can pull in the required packages via pip/pipx, it'll run Reticulum.
- On 32-bit x86 platforms it has to build the PyCA/cryptography module, but works fine after it does that.
- Reticulum supports a number physical interfaces, serial is one of them. It of course has the "RNode" intefaces for LoRa radios. For Ethernet, there is "AutoInterface" which uses IPv6 autoconfiguration for peer discovery and IPv6 UDP for transport but doesn't rely on DNS, DHCP, or anything else. If your PC, phone, or other involved devices on the same network have IPv6 enabled and no filtering is happening on layer 2 then it's dead simple - any device there will see announces from others and be able to transact with you not doing much more than spinning up MeshChat.
- Other interface types are TCP client, TCP server, IPv4 UDP, I2P, and a pipe interface. The pipe interface is interesting as it's basically stdin/stdout to an executable of your choice, so you can use that to make Reticulum available over really anything you could dream up, such as an SSH tunnel.
The only fully-functional stack currently available requires Python >= 3.8, which is the main limitation to where it will run. But there’s still a lot you can do with that!
there is a pretty compatible rust implementation as well which claims to target microcontrollers https://github.com/BeechatNetworkSystemsLtd/Reticulum-rs
Did you use it? I've never seen it used outside of Beechat's own devices.
Popular in 2022 (95 points, 15 comments) https://news.ycombinator.com/item?id=30870187
... urgently needed now ;)
Sounds like someone is a fan of Anathem!
How does this differ from meshtastic? Is meshtastic just more chat based and this is more generic?
Reticulum is a full network stack with full user anonymity. You can integrate it in every app that needs P2P network connections and that can live with a slow connection. Reticulum is an alternative to TCP/IP and UDP/IP, using a mesh.
Meshtastic and Meshcore are mesh messengers, focusing on mesh text messages.
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.
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.
Mark's Reticulum implementation has a strong ideolgical background. Not just the oppositon to AI. If anybody is interested in what drives the developer, here's the manifesto: https://github.com/markqvist/Reticulum/blob/master/Zen%20of%...
I saw this too and immediately thought: well, they published this on GitHub which surely has a clause that grants it a license to use the code for training Copilot for Microsoft at a minimum, sooo should've published on another Git platform.
> This repository is a public mirror. All development is happening elsewhere.
So if I have code on a personal (but publicly exposed) git server with a license that includes the above quoted terms, and someone decides they want to be helpful and publish a public read-only mirror of my code to GitHub, then they’re allowed to accept that license on my behalf? I never did a thing and yet I’m now in a contract with Microsoft? How does this work legally?
Not a lawyer but I'm pretty sure:
1. Microsoft does not gain the license, but will be able to argue that they aren't intentionally committing copyright infringement in the cases where that distinction matters.
2. If Microsoft does something resulting in damages because they thought they had a license, their indemnification clause kicks in and they can recoup those damages from the user who uploaded it (to the extent that that user doesn't go bankrupt anyways)
3. Likely none of this matters because your license can't prevent activities that weren't prohibited by copyright in the first place, and training doesn't appear to be a prohibited activity at least under US law.
When code is published on GitHub, GitHub itself is not bound by the public-facing license, but rather license grants the uploader aggress to as part of the terms of service. That points to the uploader as a responsible party.
In practice though, none of that is even remotely enforceable.
Not sure GitHub has such a clause. Just looked at their terms and don't see it.
See term D.4., the relevant part of which is
> You grant us and our legal successors the right to store, archive, parse, and display Your Content, and make incidental copies, as necessary to provide the Service, including improving the Service over time. This license includes the right to do things like [...] or otherwise analyze it on our servers; share it with other users
That could be boilerplate legalese for "obviously we need access to your code if we're to display and share it (as is the purpose for a public git host)"
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?
all users need to be running the reticulum network stack to be able to send, receive, and route packets.
reticulum itself describes the network stack (like tcp/ip) and it has its own protocols like LXMF for messaging and LXST for streaming. applications can be built on top of these protocols.
it’s different than IP, instead of addresses, each node has an identity that’s a cryptographic key pair that you send messages to, the routing happens in the background regardless of network topology or diversity of link types.
you CAN send reticulum packets over a TCP/IP adapter and thus across the normal Internet (there are a lot of testnet and community nodes that are accessed this way), but the protocol also seamlessly bridges over any interface (lora, bluetooth, HAM radio, etc) that is attached to the node.
so like, there could be a message sent over lora to a base station that relays it to another server through the internet, then that server sends it out over a ham radio link to another computer somewhere else, etc.
all the message sender has to know is the pubkey of the node they want to talk to, and the network figures out how to establish a link.
128 hops maximum.
the prerolled binaries of the aforementioned software include the network stack and easy enough presets to find content from other nodes and people to talk to.
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.
Anybody have any experience running this on a tdeck? I'm kinda toying with the idea of ordering a couple just to play with.
It is not yet like meshtastic in that. Rnode is more of a lora modem than a lora server. There is a micro recticlum project but not out yet.
Such a nasty name for a good project ;-;
Sounds too close to "rectum".