Hacker News Reader

Comment by SuperMouse | Hacker News Reader

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.

View on HN

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

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.

- [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

Just found this post; and I see Liam Cottle _just_ did a talk at FOSDEM26 about the situation and the future:

https://fosdem.org/2026/events/attachments/9NCWUR-reticulum_...

To be fair, satoshi stepped back too.

Yea, because he was dying.

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.

Unsurprisingly:

> 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

> I've never seen a bigger network with Reticulum in the wild.

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.

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.

> 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.

So numbers stations fall under as otherwise provided?

No, numbers stations are not permitted on amateur frequencies in the US. There are some notable cases of foreign governments setting these up and interfering with amateur allocations [1], but there's not much the FCC can do about that.

[1] https://www.arrl.org/news/russian-buzzer-disappears-chinese-...

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 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.

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)

How many text messages does each user send per hour? Or how many are in active chat with each others at a given time?

(Careful that the US have a 400ms dwell time depending on settings that can put a significant limit on things/range)

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

Big fan of MeshCore; been using it recently and it Just Works. Especially where I am in the USA Pacific Northwest, the mesh is always hopping with conversation. I have run into delivery issues a single digit number of times over hundreds of messages.

If you're talking radio mesh, then MeshCore and Meshtastic. Meshcore does chat much better than Meshtastic.

Meshtastic is good if you're in a remote location, and you want to connect a bunch of sensors and trackers.

Reply on news.ycombinator.com