Hacker News new | ask | show | jobs
by WD-42 53 days ago
Capping off a pretty wild week for Meshcore: https://www.pedaldrivenprogramming.com/2026/05/meshcore-is-h...
1 comments

TBH Meshtastic's code isn't great either. It's neat to play with but not robust.
It sucks how everything feels like a toy. I think meshtastic is the closest thing to a “product”. They made a bunch of bad architectural decisions that are haunting them now like how nodes broadcast its info.
It doesn't surprise me. This is a deep networking problem and very few CS people know anything about networking or how to design clean, fast, low-overhead network protocols and systems.

If IP were designed today the packets would have 500+ bytes of plain text JSON as headers and the spec would support hundreds of extensions.

Is there a better designed mesh project like those two getting built that you know of? Reticulum?
It's a fundamentally really hard problem that looks easy on the surface. There is no solution that works well beyond the small scale. Many people have tried. It's the same kind of thing that draws people to try to write IPv8.
Yeah, openmanet with reticulum seems the most “professional” right now
Heh nice, I have 4 openmanet nodes on HaLow right now
Have you seen that IPvwhatever proposal from a handful of weeks back that has OAuth/OIDC in packet spec
7 OSI layers were too many. What if we ONE BOG ONE!
Because they are toys. For real work it makes so much more sense to use the internet. With the new satellite tech you can reach the internet everywhere.

Mesh radio is a fun way to chat with radio nerds in your area. Not a serious infrastructure.

So what’s the real solution for when Starlink is too expensive and too high power? I really want to solution for remote mountaineering communication that’s not just GMRS. And what about remote weather sensors? I really don’t need a full internet connection just to send a tiny payload every 5 minutes.

Meshtastic should be the obvious answer for this but in my limited experience the app(s) and code are buggy on even the most typical hardware. Wish it wasn’t the case but it is.

How remote is "remote"?

If you're talking about a few miles/KMs between nodes, plain old LoRaWAN might be more than sufficient, esp. for the sensor use case. The nice thing about using LoRaWAN is that's it's literally providing an IPv6 overlay so you can run e.g. MQTT or a text-based messaging protocol designed for regular TCP/IP use. UDP is preferable to avoid frequent session resets and keepalive traffic chewing up your available bandwidth.

Meshtastic and MeshCore can theoretically provide "infinite" range so long as there are peers between the nodes you want to connect. Theoretically, mobile peers can also serve as store-and-forward nodes so that reachability doesn't need to be constant, just frequent enough to handle the messaging you want to do.

I would absolutely not rely on either for a safety-critical application, though. If you want emergency comms in case something happens while you're out on the mountain, use a satellite communicator. There are a ton of these marketed for outdoor/portable use, and they have much more robust "SOS" capabilities (up to and including direct dispatch of search-and-rescue).

LoRaWAN seems interesting but the documentation and availability of is either "Crypto hobby project from Seedstudio" or "Strange telecom companies selling $900 base stations that still expect an internet connection (for licensing?)". Maybe I'm missing something but the LoRaWAN doesn't see to sell itself very well when half the vendors are behind "Contact for quote" pages.

Of course, for real emergencies I have a Garmin SOS device. It would just be "nice" to have something for local 2-5 km communication that doesn't need a clear view of sky, works partially underground, etc. GMRS is "fine" but from a physics perspective a digital signal with Chirp encoding should go further and be more reliable.

Seems like JS8Call or Packet radio might more in line with what I want. It's just surprising that something like Meshtastic hasn't replaced them.

Is there any implementation of the store and forward for mobile nodes?

From what I recall, meshcore de duplication only tracks like the last 256 messages so that could quickly fail to de duplicate.

Depends what exactly it is you want. But phones these days can communicate with satellites for emergency messaging.

I think people need to think more about what the actual scenario they have in mind is because it seems most people think of mesh radio as some backup for the government shutting the internet down. When in reality it’s almost useless for that since it’s so easy to jam or flood mesh radio.

For emergency communication? Iridium, zoleo, JS8Call, packet radio.

Not LORA.

We may see a day when the internet is not available, or when interacting with it represents an unacceptable risk. It's a good idea to know how to set up your own.
In that day whatever is jamming starlink will just jam mesh radio too. It'll likely be even easier.
It's a different jamming scenario however. Starlink is comparatively centralised, and reliant on both terrestrial (ground stations) and satellite communication. While the terminals themselves are sparse and widely distributed, the backbone infrastructure is far less so. It's possible to target the satellites, ground stations and critical service dependencies (e.g. GPS) rather than needing to target the hundred of thousands/millions of terminals directly.

The mesh networks are dealing with, by definition, a sparse and widely distributed set of devices which are independently configured and controlled, and in their current widely available form are only dealing with terrestrial communication. Without that point of centralisation you would need to focus on targetted regional jamming, as from a practical standpoint you cannot perform wideband RF jamming over an entire country - signal jammers don't scale that well, and geographic features come into play. As an example you might effectively block mesh networks from operating reliably in a given city, but if people were to move outside of that area then the mesh would operate again. Geography is both a strength and a weakness here: a mountain range will impede direct communication with someone on the other side, but it will also have the same effect on jammers which will vastly increase the cost to deploy them in a ubiquitous fashion.

That’s really the killer for survivalist mesh ideas. It’s trivially easy to jam, and if it’s open it’s also easy to DDOS.

Jamming is done in military scenarios too, but in that case it’s limited by the fact that a jammer is a big transmitter painting itself with a big sign that says “fire missile here.” Civilian mesh doesn’t have that fallback.

Probably not short range connections. The application layer will have to change but we can still have an internet that operates when we pass each other on the street or share an elevator--the primary bandwidth carrier being devices being physically moved through space, and cross-device chatter being opportunistic.

Also, it might not be jamming. It might be that whoever is operating the satellites at the time denies access unless you enable inspection, and then sells that info to somebody who would hurt you--or whatever other can't-trust-the-middleman dystopia you care to imagine.

> not a serious infrastructure

I've been tinkering with the tech to make city-wide flrc meshes joined together over the internet, my estimates are that it should be at least able to support thousands of users per region.

This has been tried with mqtt bridges in Meshtastic. But it’s ultimately kind of pointless because if you are planning some kind of internet alternative, you don’t want to build something that falls over the moment the internet goes down.
I know, I'm not too worried that I can't reach Billy in Ottawa, but you should still be able to text your mother six blocks away. /shrug
True. But look at the situation in Iran. As much as internet seems like an essential part of daily life, there is the possibility for the governments to shut it down.
Usability wise Meshcore is better due to static routing and enabling (far) longer paths.
And also them calling out Andy for they key? Stupid.

The official Android app (blessed by the "community") still has in-app purchases up. It gates the remote repeater management, afair one of the things Andy's MeshOS app for TDeck is gating.

The underlying protocol is open source, but the companion app isn't.

Yes, in the current version of Meshcore app it's possible to manage the repeater without the key, after a wait period, but that changed recently and they still nudge towards in-app purchase.

Similarly Andy's firmware* can be used for free, without purchasing a key, unless the user wants the full functionality.

*is it even his, considering it's been AI-generated?

A big mess. Also the network is a big mess, now I understand why.