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 :(.
The reticulum dev have been trying to quit for years and have been quite open about his own personal struggles.
More recently:
- v1.0.0 was supposed to be the time his involvement is over [0]
- 6 months later [1]
> This is not a temporary break. It's not "see you after some rest", but a recognition that the current model is fundamentally incompatible with my life, my health, and my reality.
- But he pushed 3 releases since his last message [2]
It is like he is trying to quit somking.
I am not sure what the problem is exactly but it seems someone need to take over and honor the fantastic work he has done over the years.
> 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.
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 :).
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.
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.
> 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.
> 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.
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 the 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.
>I believe that Meshtastic uses the whole 250kHz of that subband by default. This is by far the most relaxed constraints of what is available in the EU and US.
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 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.
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.
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.
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.
> 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.
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?
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.
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.
Reticulum is not nominally for lora/sx radios. It is designed to operate over any transport from a serial link or infrared to high speed wireless lan or multi-gigabit ethernet.
I hadn't heard of this. It sounds like then you'd need a dedicated radio co-processor that is just running their firmware. Then, connect to it via [SPI?] to your main MCU or similar.
You can run it on a common board like a Heltec LoRa 32 (can’t remember if it supports v3 or just v2). I played around with it some, but mostly stick with Meshtastic.
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.
The first ... few hundred pages were tough, between that and the massive amount of world building (which I enjoyed, but there is a lot.) I was lucky to make it over the hump as I find out well worth it.
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.
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
More recently:
- v1.0.0 was supposed to be the time his involvement is over [0]
- 6 months later [1]
> This is not a temporary break. It's not "see you after some rest", but a recognition that the current model is fundamentally incompatible with my life, my health, and my reality.
- But he pushed 3 releases since his last message [2]
It is like he is trying to quit somking.
I am not sure what the problem is exactly but it seems someone need to take over and honor the fantastic work he has done over the years.
- [0] https://unsigned.io/articles/2025_05_09_The_End_Is_Nigh_For_...
- [1] https://unsigned.io/articles/2025_12_28_Carrier_Switch.html
- [2] https://github.com/markqvist/Reticulum/releases
> 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
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/
[0]: https://yggdrasil-network.github.io
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.
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 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.
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.
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.
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.
Again wrong, just look at EU vs US:
https://meshtastic.org/docs/configuration/radio/lora/#region
> beyond extremely small meshes, if at all.
180 online nodes (300 at max) is not extremely small (and that's our small mesh EU with medium_fast)
(Careful that the US have a 400ms dwell time depending on settings that can put a significant limit on things/range)
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.
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.
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.
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.
> 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.
> 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?
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.
- 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.
Meshtastic and Meshcore are mesh messengers, focusing on mesh text messages.
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.
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
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.
It's quite a tough read for me with such an alien vocabulary.
Anyway, good to know it's not meant to resemble anything nasty.