We're using Meshtastic quite extensively for communication on our boat. Each crew member carries a mobile waterproof node (Seeed T1000e), the boat itself has a node, and we also have a Meshtastic tracker for the dinghy.
We often sail in places where there's no communication infrastructure, or it is prohibitively expensive. With Meshtastic we can talk when somebody goes ashore, and the boat can send telemetry and alerts to the remote crew.
Some of our buddy boats also have Meshtastic on board so we can text chat with them instead of using VHF.
The only real problem I foresee with this use(fantastic use case btw) is if you travel across regions, does the kit currently get automatically switched to correct frequencies and power limits?
No, you need to switch the region manually. Not a big deal to do for a couple of nodes.
The trickier part is to figure out the correct preset for more exotic locations. I've had to ask a couple of times from the local Meshtastic community group.
Many (if not most) Meshtastic devices don't have a GPS receiver of their own, and also may not be paired with a phone app to supply location. So at least some devices would need to sniff GPS coordinates from traffic on the wrong band in order to know it's time to switch to the new band appropriate for the new location. Some amount of automatic reconfiguration could probably be made to work, but there would be serious limitations on how many use cases it could handle.
I think the way to do it would be that you have GPS run a update script to sync the devices. Surely the boat has a GPS, right? Or there's a GPS somewhere in the system.
So to refine the gp's question: surely there's a way to push an update or sync with a script that can do this based on GPS coordinates, right?
I would think a syncing mechanism would be a big help anyways since regardless of the reliability of the GPS script you're still going to be doing this, right?
I have a few LoRa radios running Meshtastic and they're fun to play with, but I wouldn't rely on them in a critical situation. It's too easy to accidentally configure a node incorrectly and cause problems for nearby nodes.
Perhaps someday the project will settle on a handful of sensible presets for different use cases. Even better would be if more of the options were managed dynamically by the software itself, things like adjusting timeouts and hops based on current network utilization and previous transmission success rate, or automatically tweaking the role based on the current mesh toplolgy, that sort of thing.
We need better radio silicon that can survey a wide swath of available spectrum (based on country limits) and pick channel(s) appropriate to the use optimized for battery life, distance, and/or bandwidth with a simplified interface. There's no sense wasting spectrum or having malfunctioning radio gear when it can be standardized and used more efficiently without an artificial, protectionist, hoarding monopoly (excluding particular essential, prioritized uses).
Proprietary mesh networks tend to become unusable garbage because they omit DoS, rate limits, and proper configuration for dense metropolitan uses, and tend to fail at investing in upkeep.
> better radio silicon that can survey a wide swath of available spectrum (based on country limits) and pick channel(s) appropriate to the use optimized for battery life, distance, and/or bandwidth
That would certainly be helpful, but even with current radios I can imagine a configuration process that sequentially scans different channels to achieve the same result, just a little slower.
A full scan would take hours. With just the default choice of channel width (250 kHz), spreading factor and coding rate, in the US you'd have to listen to 104 different frequencies, and you'd need to listen for more than a minute to get any idea of whether each frequency is in use. The newest LoRa chips that support simultaneously monitoring multiple spreading factors aren't yet supported by Meshtastic or available in cheap devices. The base station chips that also support listening to eight frequencies at a time are way more expensive.
Even with the latest radios available but not yet used by Meshtastic, it would be very hard to implement any kind of frequency-hopping scheme or variable bandwidth, without requiring mesh nodes to burn a lot more power sending and receiving+acknowledging across multiple modem settings to maintain reliability. LoRa as implemented by the chips used in affordable Meshtastic devices is really more suited to operating many small disjoint mesh networks on separate channels, not one large mesh network spanning multiple frequencies/bandwidths/etc. (Dropping the ad-hoc mesh aspect in favor of centralized coordination is pretty much the only way to scale up to large networks.)
> LoRa as implemented by the chips used in affordable Meshtastic devices is really more suited to operating many small disjoint mesh networks on separate channels
My impression was that many of the folks who wanted a big shared mesh migrated to MeshCore, which I'm less familiar with. My use case is in fact a small disjoint mesh network, but even that requires proper configuration and can be unreliable due to things like misconfigured nodes (mine or others).
I'd be happy to specify the region and form factor (handheld, fixed router, mobile router, tracker) but it would be nice if the nodes could automatically configure the right role, rebroadcast mode, hop limit, timeouts, etc on their own. I'm not asserting it's possible, just that I don't otherwise see it breaking out of the hobbyist niche.
> A full scan would take hours.
My apologies, I misspoke, I agree that trying every frequency/bandwidth/spread factor/coding rate combination would be impractical, at least for battery-powered nodes. Instead of "scan different channels" I should have said cycling through the half-dozen modem presets for a specific region.
Huge fan of Reticulum, fixes some of my biggest gripes with Meshtastic. Shame it hasn't got as much adoption yet. For those looking for Meshtastic-equivalent things in the Reticulum ecosystem:
Didn't got adoption because the code base is awful to work with and there is a trauma against bluetooth being used as a network path.
Plus: encryption is heavy when bandwidth is limited and over radio waves we aren't even permitted to encrypt data most of the times.
Please don't read my comment as bringing down the project. I'm a fan, used everything it was produced but ultimately is unusable for serious applications on the current state. I really tried hard to adopt it.
If the reticulum code is worse than the meshtastic one, then it is truly atrocious. Been trying to get a specific board to simply "sleep" its radio using meshtastic, and nobody seems to know WHY it doesnt do it. The code is horrible spaghetti with lots of ifdefs. And nobody seems to know why things are the way they are in the code re: power handling. ChatGPT wrote me a brute force method that works, but its ugly and I dont want to maintain patches.
But it is fairly easy to hack on. I have no idea how to debug things without USB serial connected, though.
Sorry, can't really compare because I've never had to suffer looking at meshtastic source code. Quite tempted at this point to just throw the python implementation of reticulum at Claude and see if a validated port to C++ is possible.
Maybe a bit offtopic and not LoRa, but I've been looking at ESP32 and they include an ESPMesh for the WiFi radio with a promise of about 500 to 1000 meters range from what I read. It isn't the same range as LoRa, but it is "larger" bandwidth and for the price of 3 dollars per unit seems promising on urban areas to connect people. I'm trying it out now.
What are those gripes? If I don't have anyone else who would use it, but would hang out in a public chat room, it didn't seem like reticulum was the right choice for that? You need destinations on things?
It seems like big cities get congested, on marginal systems the chances of only getting half the messages is very high. It really dosnt integrate with much else, the mqtt stuff seems unreliable.
It does seem like the RNode radios are a lot less mature but they seem to be aiming to be less of a toy.
Nomadnet it's really bad; it doesn't properly work with a 80x24 terminal and 16 colors.
Also, it uses tons of CPU on legacy machines. It needs some rework.
Not everyone it's a hipster with 256 or 32 bit colour terminals, shitty NerdFonts (nonstandards) and big displays.
And being written in Python3 makes it dog slow. Being rewritten in Go would get a few performance tweaks, (networking and GC there it's ideal), security and portability. But, please, no BubbleTea unless you can be sure it can work on a plain XTerm with 16 colors (I use Tango for readability, but 16 colors FFS). Keep 256 colours as an option.
One of the main differences with MeshCore is that client nodes don't repeat messages, only dedicated repeater nodes repeat with the idea that they should be placed in more ideal locations.
Just don't mention MeshCore anywhere around Meshtastic, or they'll kickban you.
> Just don't mention MeshCore anywhere around Meshtastic, or they'll kickban you.
Thats not the problem. And Ive also mentioned Meshcore as well on their discord with no threats of banning or anything of the sort. Ive also seen people come in the group, with "Meshtastic sucks and Meshcore is best", and the worst by admins was 'we have no problem discussing but that tone was overly harsh'.
Liam Kottle, the head of Meshcore ran the first Meshtastic map from grabbed MQTT data. However, he was grabbing and saving everything, including public channels, direct messages, GPS, telemetry. Everything. 1.5y ago, people were going to his map and snooping on Defcon Meshtastic DM's, since even 1 node who reported MQTT would send everything. And then, DMs were simply filtered by the UI, but were effectively encrypted by the same shared key.
Normally there was a general expectation that the data was ephemeral. Liam basically created and caused this data problem by saving and making available everything sent to MQTT.
Meshtastic devs ended up having to tighten down the public MQTT broker a bunch. They also made the client on phones be more restrictive what was done and sent to MQTT. Also made "OK to forward MQTT" flag in the data packets too. And 2.5 introduced PKI TOFU for direct messages to prevent leakage.
Aside the personnel difficulties, the technical issues with Meshcore are similar at node capacity too. Messages still dont get delivered near capacity. Core requires infrastructure nodes. Its more like APRS+LoRa than anything like a mesh.
It's unfair to assign that much blame to assign to any one person. I think it's more fair to say that the Meshtastic community as a whole has a problem with people making overly-narrow assumptions about the goals and what use cases Meshtastic is intended for, suitable for, or usable for. As a result, the community was able to do a lot of development work seemingly without considering that there could even be privacy concerns. And then they had to scramble to retrofit a lot of privacy controls that would have been obvious requirements all along to people coming at the project with a different mindset.
Some people want Meshtastic to be rock-solid communication infrastructure for use in a doomsday or disaster scenario. Some people want to use it to undermine the importance of cellular communications networks. Some people want it to be used much like CB radio as a local public conversation channel. Some people envision it used mostly with stationary transmitters, while other people want to use it entirely with mobile nodes. I use it primarily for group location sharing (many to many), since the location sharing capabilities Apple and Google provide for their smartphone platforms only easily support one-to-one or one-to-several location sharing.
It seems that at scale meshcore is much better. The more nodes you get, the worst it gets with Meshtastic after a certain point. For meshcore you now have entire regions connected in a single mesh with hundreds of nodes.
Agreed. Ran the comms for my burning man camp and everyone kept getting confused with the channels mess among other usability issues. I like where Mesh core is going, just wish the repeater nodes could run on gateway hardware so they don’t become the choke point with a half-duplex radio (bs like 8 full duplex channels on the RAK wireless gateway)
Meshtastic: Text message mesh network using LoRa modems.
Reticulum: full network stack (alternative to IP), mesh, focus on low-speed, unreliable connections. Transport layer agnostic. Current 'Hardware drivers' are written for LoRa, Internet Tunnels, Wifi, Amateur radio.
Reticulum sounds great? It is, but still has 2 problems: 1. The only complete & stable implementation is written in Python and 2. The existing end-user applications have confusing and complex UIs (except for the command-line tools for remote shell and file copy).
First I've heard of this. My initial reaction is why oh god why this name. I liked Anathem, but seriously you're not going to using this as the Internet 3000 years from now.
Meshtastic at first glance seems silly. No routing, one spammer could mess up the whole thing. Hopefully this is better.
Meshtastic is reasonably good for unplanned and mobile use cases such as hiking, but for building an emplaced network, Meshcore has much better performance.
This has been our experience in the Greater Boston Mesh.
Is there a mesh network solution with very low bandwidth by design? "by design" meaning that participants of the network aren't able to increase their bandwidth beyond a defined upper limit. I'm thinking of a bandwidth of about 10kbps. The low bandwidth would practically eliminate problems around spamming and cp. The idea is a network that is only useful for exchanging texts/messages and accessing simple text based websites.
Meshtastic already fulfills that, except for the bit about accessing simple text-based websites, because Meshtastic isn't an IP network. The data rates only go up to 21.88 kbps for the fastest preset: https://meshtastic.org/docs/overview/radio-settings/#presets
the idea is that there would be no point in visiting anything else than text based web-sites or use text-based services. or do you mean that it can't be hooked up to the internet due to its lack of IP protocol?
How far can Meshtastic go, it seems using LoRA. How is it different from VHF/UHF based radio that can do 30+ miles using handheld where no cellular power exists(off-grid communication), or the 5-mile walkie-talkie. My assumption is that Meshtastic has the advantage of low-power that can sustain much longer time.
Another forthcoming alternative will be satellite-based chat using phones.
For a single hop you can expect close to similar ranges as a VHF set. We saw 30NM distances on open sea when leaving Curaçao. Could be a lot more with antenna situated high up.
Where the magic potentially kicks in is the mesh hops. With those you can reach much further by jumping from one node to another.
It's not even close to satellite comms in reach or reliability, but it also requires no infrastructure, no licensing, and no subscriptions.
Meshtastic is multi-hop, doesn’t require a license and is encrypted by default. It’s also a toy network, really. Reliability doesn’t seem to be high on the priority list.
Reliability carries serious costs in airtime usage and power consumption, and there's always going to be someone who demands that the network support an even higher level of reliability. "Toy network" is highly subjective and depends on your (unstated) assumption about what kind of use case you want Meshtastic to fulfill.
My wife and I tried to use Briar to communicate after we had been reallocated two seat rows apart in a flight. It didn't work at all. Messages arrived hours later, when they arrived.
Meshtastic is interesting because it's basically "LoRa-first networking" instead of "internet with some radios attached." Most consumer radios are still stuck in the mental model of walkie-talkies, while Meshtastic treats RF as an IP-like transport layer you can script, automate, and extend. That flips the stack: your primary network can be intermittent, off-grid, and low bandwidth, and the internet becomes an optional upgrade instead of a dependency.
The bigger story is that this is what "local-first" looks like in the physical world. Phones are powerful computers that are useless as soon as the tower or backhaul goes down; a $20 LoRa board suddenly becomes the only reliable "infrastructure" in range. Once enough people carry something Meshtastic-compatible, you get the weird inversion where the cheapest, dumbest devices are the ones that keep working when the expensive, smart ones don't.
And not even the ones who carry them, just a half dozen well-placed reliably powered router nodes can massively increase the range of the network in general.
You can get plug&play ones from seeedstudio for $100-ish, solar panels and batteries included.
What do you even mean by "AI agent"? I've head that term used in a few different ways, but none of them are at all close to anything that would benefit from an off-grid ad-hoc dialup-speed communication channel between agents (as opposed to between an agent an a human or non-AI service).
For the last 2-3 years I've been "this close" to getting a few devices and setting up a repeater node on my home roof and my office roof, and one to play with... I love the idea of bringing an alternative to SMS to my area. But at the end of the day, is anyone actually using it for anything?
This community is laughably caustic and abusive. My friend attempted to create a simple tutorial site and their org harassed him for over a year. He didn't even mention the word "meshtastic" and they made dozens of false trademark claims that his site could be "confused" with an official site.
I was previously a fan, but I'd never seen behavior like that from an "open source" project.
You’re understating it. Meshtastic is horribly designed. If you designed a wireless mesh network making all the worst possible choices, with the most shortsighted design decisions imaginable, you’d get something a little better than Meshtastic.
We're using Meshtastic quite extensively for communication on our boat. Each crew member carries a mobile waterproof node (Seeed T1000e), the boat itself has a node, and we also have a Meshtastic tracker for the dinghy.
We often sail in places where there's no communication infrastructure, or it is prohibitively expensive. With Meshtastic we can talk when somebody goes ashore, and the boat can send telemetry and alerts to the remote crew.
Some of our buddy boats also have Meshtastic on board so we can text chat with them instead of using VHF.
Here's a story describing this: https://blog.noforeignland.com/off-grid-boat-communications-...
The only real problem I foresee with this use(fantastic use case btw) is if you travel across regions, does the kit currently get automatically switched to correct frequencies and power limits?
No, you need to switch the region manually. Not a big deal to do for a couple of nodes.
The trickier part is to figure out the correct preset for more exotic locations. I've had to ask a couple of times from the local Meshtastic community group.
There’s no reason this can’t be done in software though via GPS, right?
Many (if not most) Meshtastic devices don't have a GPS receiver of their own, and also may not be paired with a phone app to supply location. So at least some devices would need to sniff GPS coordinates from traffic on the wrong band in order to know it's time to switch to the new band appropriate for the new location. Some amount of automatic reconfiguration could probably be made to work, but there would be serious limitations on how many use cases it could handle.
I think the way to do it would be that you have GPS run a update script to sync the devices. Surely the boat has a GPS, right? Or there's a GPS somewhere in the system.
So to refine the gp's question: surely there's a way to push an update or sync with a script that can do this based on GPS coordinates, right?
I would think a syncing mechanism would be a big help anyways since regardless of the reliability of the GPS script you're still going to be doing this, right?
I think the primary problem is that the polygons for regions would take quite a bit of space in the limited microcontroller.
Though bigger reason likely is that very few people actually travel between different regions
This is really cool; it's the merchant marine equivalent of the flight park near me which uses meshtastic for glider tracking/comms (secondary).
Lots of LoRa stations nearby.
I have a few LoRa radios running Meshtastic and they're fun to play with, but I wouldn't rely on them in a critical situation. It's too easy to accidentally configure a node incorrectly and cause problems for nearby nodes.
Perhaps someday the project will settle on a handful of sensible presets for different use cases. Even better would be if more of the options were managed dynamically by the software itself, things like adjusting timeouts and hops based on current network utilization and previous transmission success rate, or automatically tweaking the role based on the current mesh toplolgy, that sort of thing.
We need better radio silicon that can survey a wide swath of available spectrum (based on country limits) and pick channel(s) appropriate to the use optimized for battery life, distance, and/or bandwidth with a simplified interface. There's no sense wasting spectrum or having malfunctioning radio gear when it can be standardized and used more efficiently without an artificial, protectionist, hoarding monopoly (excluding particular essential, prioritized uses).
Proprietary mesh networks tend to become unusable garbage because they omit DoS, rate limits, and proper configuration for dense metropolitan uses, and tend to fail at investing in upkeep.
> better radio silicon that can survey a wide swath of available spectrum (based on country limits) and pick channel(s) appropriate to the use optimized for battery life, distance, and/or bandwidth
That would certainly be helpful, but even with current radios I can imagine a configuration process that sequentially scans different channels to achieve the same result, just a little slower.
A full scan would take hours. With just the default choice of channel width (250 kHz), spreading factor and coding rate, in the US you'd have to listen to 104 different frequencies, and you'd need to listen for more than a minute to get any idea of whether each frequency is in use. The newest LoRa chips that support simultaneously monitoring multiple spreading factors aren't yet supported by Meshtastic or available in cheap devices. The base station chips that also support listening to eight frequencies at a time are way more expensive.
Even with the latest radios available but not yet used by Meshtastic, it would be very hard to implement any kind of frequency-hopping scheme or variable bandwidth, without requiring mesh nodes to burn a lot more power sending and receiving+acknowledging across multiple modem settings to maintain reliability. LoRa as implemented by the chips used in affordable Meshtastic devices is really more suited to operating many small disjoint mesh networks on separate channels, not one large mesh network spanning multiple frequencies/bandwidths/etc. (Dropping the ad-hoc mesh aspect in favor of centralized coordination is pretty much the only way to scale up to large networks.)
> LoRa as implemented by the chips used in affordable Meshtastic devices is really more suited to operating many small disjoint mesh networks on separate channels
My impression was that many of the folks who wanted a big shared mesh migrated to MeshCore, which I'm less familiar with. My use case is in fact a small disjoint mesh network, but even that requires proper configuration and can be unreliable due to things like misconfigured nodes (mine or others).
I'd be happy to specify the region and form factor (handheld, fixed router, mobile router, tracker) but it would be nice if the nodes could automatically configure the right role, rebroadcast mode, hop limit, timeouts, etc on their own. I'm not asserting it's possible, just that I don't otherwise see it breaking out of the hobbyist niche.
> A full scan would take hours.
My apologies, I misspoke, I agree that trying every frequency/bandwidth/spread factor/coding rate combination would be impractical, at least for battery-powered nodes. Instead of "scan different channels" I should have said cycling through the half-dozen modem presets for a specific region.
regional meshes may have suggested configuration. for example bay area mesh https://bayme.sh/docs/getting-started/recommended-settings/
i installed a node week ago. honestly, it is somewhat underwhelming
If you're underwhelmed (in the Bay Area?) imagine how underwhelming it has been in Omaha, Nebraska, ha ha.
I played a bit with them. There was one node anyway about 6 miles from me.
did you get omaha steaks ads over meshtastic ?
Alternatively…
https://reticulum.network/
Huge fan of Reticulum, fixes some of my biggest gripes with Meshtastic. Shame it hasn't got as much adoption yet. For those looking for Meshtastic-equivalent things in the Reticulum ecosystem:
- Sideband: iOS/Android chat app (https://github.com/markqvist/Sideband)
- NomadNet: Desktop CLI chat app (https://github.com/markqvist/NomadNet)
- Rnode: Reference node hardware/firmware (https://unsigned.io/rnode/)
Didn't got adoption because the code base is awful to work with and there is a trauma against bluetooth being used as a network path.
Plus: encryption is heavy when bandwidth is limited and over radio waves we aren't even permitted to encrypt data most of the times.
Please don't read my comment as bringing down the project. I'm a fan, used everything it was produced but ultimately is unusable for serious applications on the current state. I really tried hard to adopt it.
If the reticulum code is worse than the meshtastic one, then it is truly atrocious. Been trying to get a specific board to simply "sleep" its radio using meshtastic, and nobody seems to know WHY it doesnt do it. The code is horrible spaghetti with lots of ifdefs. And nobody seems to know why things are the way they are in the code re: power handling. ChatGPT wrote me a brute force method that works, but its ugly and I dont want to maintain patches.
But it is fairly easy to hack on. I have no idea how to debug things without USB serial connected, though.
Sorry, can't really compare because I've never had to suffer looking at meshtastic source code. Quite tempted at this point to just throw the python implementation of reticulum at Claude and see if a validated port to C++ is possible.
Maybe a bit offtopic and not LoRa, but I've been looking at ESP32 and they include an ESPMesh for the WiFi radio with a promise of about 500 to 1000 meters range from what I read. It isn't the same range as LoRa, but it is "larger" bandwidth and for the price of 3 dollars per unit seems promising on urban areas to connect people. I'm trying it out now.
What are those gripes? If I don't have anyone else who would use it, but would hang out in a public chat room, it didn't seem like reticulum was the right choice for that? You need destinations on things?
We have a relatively dense meshtastic in my city, and yet I can't reliably send a message across to my friend, who would be 4 hops away.
It's just not awesome. Especially compared to what you can do with ham radio.
You must live in nyc or san Francisco lol
It’s pretty dense in Portland and Seattle too, I’d image most of the bigger cities have a fairly large net
Boise, actually.
It seems like big cities get congested, on marginal systems the chances of only getting half the messages is very high. It really dosnt integrate with much else, the mqtt stuff seems unreliable.
It does seem like the RNode radios are a lot less mature but they seem to be aiming to be less of a toy.
Nomadnet it's really bad; it doesn't properly work with a 80x24 terminal and 16 colors.
Also, it uses tons of CPU on legacy machines. It needs some rework. Not everyone it's a hipster with 256 or 32 bit colour terminals, shitty NerdFonts (nonstandards) and big displays.
And being written in Python3 makes it dog slow. Being rewritten in Go would get a few performance tweaks, (networking and GC there it's ideal), security and portability. But, please, no BubbleTea unless you can be sure it can work on a plain XTerm with 16 colors (I use Tango for readability, but 16 colors FFS). Keep 256 colours as an option.
Meshcore is another alternative. I haven't done a deep dive into either but have heard that they both fix some Meshtastic issues.
https://meshcore.co.uk/
One of the main differences with MeshCore is that client nodes don't repeat messages, only dedicated repeater nodes repeat with the idea that they should be placed in more ideal locations.
Just don't mention MeshCore anywhere around Meshtastic, or they'll kickban you.
> Just don't mention MeshCore anywhere around Meshtastic, or they'll kickban you.
Thats not the problem. And Ive also mentioned Meshcore as well on their discord with no threats of banning or anything of the sort. Ive also seen people come in the group, with "Meshtastic sucks and Meshcore is best", and the worst by admins was 'we have no problem discussing but that tone was overly harsh'.
Liam Kottle, the head of Meshcore ran the first Meshtastic map from grabbed MQTT data. However, he was grabbing and saving everything, including public channels, direct messages, GPS, telemetry. Everything. 1.5y ago, people were going to his map and snooping on Defcon Meshtastic DM's, since even 1 node who reported MQTT would send everything. And then, DMs were simply filtered by the UI, but were effectively encrypted by the same shared key.
Normally there was a general expectation that the data was ephemeral. Liam basically created and caused this data problem by saving and making available everything sent to MQTT.
Meshtastic devs ended up having to tighten down the public MQTT broker a bunch. They also made the client on phones be more restrictive what was done and sent to MQTT. Also made "OK to forward MQTT" flag in the data packets too. And 2.5 introduced PKI TOFU for direct messages to prevent leakage.
Aside the personnel difficulties, the technical issues with Meshcore are similar at node capacity too. Messages still dont get delivered near capacity. Core requires infrastructure nodes. Its more like APRS+LoRa than anything like a mesh.
It's unfair to assign that much blame to assign to any one person. I think it's more fair to say that the Meshtastic community as a whole has a problem with people making overly-narrow assumptions about the goals and what use cases Meshtastic is intended for, suitable for, or usable for. As a result, the community was able to do a lot of development work seemingly without considering that there could even be privacy concerns. And then they had to scramble to retrofit a lot of privacy controls that would have been obvious requirements all along to people coming at the project with a different mindset.
Some people want Meshtastic to be rock-solid communication infrastructure for use in a doomsday or disaster scenario. Some people want to use it to undermine the importance of cellular communications networks. Some people want it to be used much like CB radio as a local public conversation channel. Some people envision it used mostly with stationary transmitters, while other people want to use it entirely with mobile nodes. I use it primarily for group location sharing (many to many), since the location sharing capabilities Apple and Google provide for their smartphone platforms only easily support one-to-one or one-to-several location sharing.
It seems that at scale meshcore is much better. The more nodes you get, the worst it gets with Meshtastic after a certain point. For meshcore you now have entire regions connected in a single mesh with hundreds of nodes.
Sad to see open source communities being so insecure that they feel threatened by an alternative project. Both can coexist and competition is good.
The Meshtastic community is almost as toxic as the ham radio one.
MeshCore app is way better than the Meshtastic one.
Agreed. Ran the comms for my burning man camp and everyone kept getting confused with the channels mess among other usability issues. I like where Mesh core is going, just wish the repeater nodes could run on gateway hardware so they don’t become the choke point with a half-duplex radio (bs like 8 full duplex channels on the RAK wireless gateway)
Meshtastic: Text message mesh network using LoRa modems.
Reticulum: full network stack (alternative to IP), mesh, focus on low-speed, unreliable connections. Transport layer agnostic. Current 'Hardware drivers' are written for LoRa, Internet Tunnels, Wifi, Amateur radio.
Reticulum sounds great? It is, but still has 2 problems: 1. The only complete & stable implementation is written in Python and 2. The existing end-user applications have confusing and complex UIs (except for the command-line tools for remote shell and file copy).
Exactly my thoughts. Reticulum feels like an eternal "one day will be great" project but we keep waiting and waiting.
After playing with meshtastic and seeing some packet-loss stats for LoRa in general, I would never even try reticulum. Sounds very, very painful.
Reticulum and Nomadnet should have been rewritten in Golang long ago.
I'm curious, what issues is python causing them?
Slow speed and CPU hogs on legacy machines such as ATOM n270 netbooks.
reticulum cannot scale, it's not topology aware and has no congestion management
First I've heard of this. My initial reaction is why oh god why this name. I liked Anathem, but seriously you're not going to using this as the Internet 3000 years from now.
Meshtastic at first glance seems silly. No routing, one spammer could mess up the whole thing. Hopefully this is better.
Popular in:
2024 (335 points, 79 comments) https://news.ycombinator.com/item?id=38829448
2022 (249 points, 90 comments) https://news.ycombinator.com/item?id=32016142
2020 (620 points, 168 comments) https://news.ycombinator.com/item?id=22540066
Thanks! Macroexpanded:
Meshtastic's Opposition to Proposed Changes on 900 MHz Band - https://news.ycombinator.com/item?id=41242091 - Aug 2024 (16 comments)
Meshtastic: An open source, off-grid, decentralized, mesh network - https://news.ycombinator.com/item?id=38829448 - Jan 2024 (78 comments)
Meshtastic is an encrypted communications platform for the Lora RF protocol - https://news.ycombinator.com/item?id=32016142 - July 2022 (88 comments)
We're making an open-source $30 GPS/mesh radio, would like advice - https://news.ycombinator.com/item?id=22540066 - March 2020 (166 comments)
Yea ppl know it but why not post again a very fun open project.
Here is part of the Berlin mesh https://potatomesh.net/
Wow Freifunk on the Teufelsberg, what a great twist of faith or whatshouldicallit :D
Meshtastic is reasonably good for unplanned and mobile use cases such as hiking, but for building an emplaced network, Meshcore has much better performance.
This has been our experience in the Greater Boston Mesh.
Is there a mesh network solution with very low bandwidth by design? "by design" meaning that participants of the network aren't able to increase their bandwidth beyond a defined upper limit. I'm thinking of a bandwidth of about 10kbps. The low bandwidth would practically eliminate problems around spamming and cp. The idea is a network that is only useful for exchanging texts/messages and accessing simple text based websites.
Meshtastic already fulfills that, except for the bit about accessing simple text-based websites, because Meshtastic isn't an IP network. The data rates only go up to 21.88 kbps for the fastest preset: https://meshtastic.org/docs/overview/radio-settings/#presets
the idea is that there would be no point in visiting anything else than text based web-sites or use text-based services. or do you mean that it can't be hooked up to the internet due to its lack of IP protocol?
I think reticulum was made for this exact purpose. It can even work on bandwidths of like bits per minutes.
How far can Meshtastic go, it seems using LoRA. How is it different from VHF/UHF based radio that can do 30+ miles using handheld where no cellular power exists(off-grid communication), or the 5-mile walkie-talkie. My assumption is that Meshtastic has the advantage of low-power that can sustain much longer time.
Another forthcoming alternative will be satellite-based chat using phones.
For a single hop you can expect close to similar ranges as a VHF set. We saw 30NM distances on open sea when leaving Curaçao. Could be a lot more with antenna situated high up.
Where the magic potentially kicks in is the mesh hops. With those you can reach much further by jumping from one node to another.
It's not even close to satellite comms in reach or reliability, but it also requires no infrastructure, no licensing, and no subscriptions.
Meshtastic is multi-hop, doesn’t require a license and is encrypted by default. It’s also a toy network, really. Reliability doesn’t seem to be high on the priority list.
Reliability carries serious costs in airtime usage and power consumption, and there's always going to be someone who demands that the network support an even higher level of reliability. "Toy network" is highly subjective and depends on your (unstated) assumption about what kind of use case you want Meshtastic to fulfill.
What about Briar / Berty
https://play.google.com/store/apps/details?id=org.briarproje...
https://apps.apple.com/app/id1535500412
My wife and I tried to use Briar to communicate after we had been reallocated two seat rows apart in a flight. It didn't work at all. Messages arrived hours later, when they arrived.
Meshtastic is interesting because it's basically "LoRa-first networking" instead of "internet with some radios attached." Most consumer radios are still stuck in the mental model of walkie-talkies, while Meshtastic treats RF as an IP-like transport layer you can script, automate, and extend. That flips the stack: your primary network can be intermittent, off-grid, and low bandwidth, and the internet becomes an optional upgrade instead of a dependency.
The bigger story is that this is what "local-first" looks like in the physical world. Phones are powerful computers that are useless as soon as the tower or backhaul goes down; a $20 LoRa board suddenly becomes the only reliable "infrastructure" in range. Once enough people carry something Meshtastic-compatible, you get the weird inversion where the cheapest, dumbest devices are the ones that keep working when the expensive, smart ones don't.
And not even the ones who carry them, just a half dozen well-placed reliably powered router nodes can massively increase the range of the network in general.
You can get plug&play ones from seeedstudio for $100-ish, solar panels and batteries included.
Seems perfect for AI agents to use to communicate to other nearby agents.
I have two of the LilyGo units and want to hook one up to the computer and then carry the other one with me.
What do you even mean by "AI agent"? I've head that term used in a few different ways, but none of them are at all close to anything that would benefit from an off-grid ad-hoc dialup-speed communication channel between agents (as opposed to between an agent an a human or non-AI service).
For the last 2-3 years I've been "this close" to getting a few devices and setting up a repeater node on my home roof and my office roof, and one to play with... I love the idea of bringing an alternative to SMS to my area. But at the end of the day, is anyone actually using it for anything?
Some of the official city supported emergency preparedness groups use it in my city. I would say it is largely a curiosity for me, like ham radio.
Been more fun to take it camping and stuff to play around with with friends.
Want to try and send one up in an RC plane soon.
In my experience, no, but still worth doing.
You end up finding and chatting (often off-mesh!) with people who are within Lora-mesh-distance of you, who have similar interests.
This community is laughably caustic and abusive. My friend attempted to create a simple tutorial site and their org harassed him for over a year. He didn't even mention the word "meshtastic" and they made dozens of false trademark claims that his site could be "confused" with an official site.
I was previously a fan, but I'd never seen behavior like that from an "open source" project.
One thing to keep in mind is that it's not even a very good mesh network.
There's a Zero Retries article recently with a critical review of meshtastic. Or find my comments on meshtastic here.
If anything they showed there's demand for a public mesh. Unfortunately, they didn't want to learn from AlohaNet or any of the other meshes.
> There's a Zero Retries article recently with a critical review of meshtastic
Do you have a link? I went through recent ZT issues and didn't find what you're referring to
Alohanet: https://en.wikipedia.org/wiki/ALOHAnet
You’re understating it. Meshtastic is horribly designed. If you designed a wireless mesh network making all the worst possible choices, with the most shortsighted design decisions imaginable, you’d get something a little better than Meshtastic.
[dead]
[flagged]
Heh, that isn't my experience.
I created a client Linux: https://gitlab.com/kop316/gtk-meshtastic-client and even posted it on their discussion page: https://github.com/orgs/meshtastic/discussions/99 . One of the maintainers responded positively to me: https://github.com/orgs/meshtastic/discussions/99#discussion... .
I have not seen that at all. Honestly, people are almost too welcoming and also maybe even too accepting of PRs for example.
[flagged]