I'm not OP, but there's a lot of criticism of meshtastic from people knowledgable about mesh networks. I also have been critical of meshtastic on this site.
I have no experience with the community, but if they couldn't have been bothered with understanding AlohaNet from several decades previous, than maybe it's not surprising.
I myself have been fairly critical of meshtastic, you can probably search for bb88 and meshtastic to find more criticisms.
To save you some time, I live in a fairly populous city with a bunch of meshtastic nodes, and can't get a message accross from me to my friend who lives one hop away.
It's not clear to me which portions of that very long newsletter are responding specifically to Meshtastic, but it seems like the most relevant section starts by listing some challenges but offers nothing in the way of solutions except to digress into talking about a wildly different class of radio hardware (SDRs that can monitor many channels at once).
"Meshtastic Is Rediscovering Lessons (Already Learned) of Amateur Radio Data Networking"
Instead of actually trying to understand the arguments these days, it's easier to inject noise into the argument, proclaiming it's too "hard to find" or "too hard to understand."
Mesh networking is a hard topic. Expect to expend some brain cells to understand it. I'm not here to spoon feed you tech that was well understood 3 decades ago.
How about you make an actual argument here in this thread, instead of vaguely gesturing at an excessively long newsletter and claiming there's relevant substance in there somewhere? Or at least tell me if I've incorrectly interpreted the "Meshtastic Is Rediscovering Lessons (Already Learned) of Amateur Radio Data Networking" section as listing problems but no solutions aside from buying a radically different (more expensive and power-hungry) type of radio?
Try making some specific suggestions for what Meshtastic is doing wrong that could be done differently. That way, we can tell whether your beef is with the Meshtastic software and protocol, or with their choice of LoRa radio hardware, or if you're just trying to preach about your ideal mesh network design with unstated assumptions about the priorities and constraints of such a network.
FWIW I have some background in this area and got curious how Meshtastic works so I read some of the docs and code. It seems like they are unaware of existing work even 20+ years ago, a specific suggestion is to study the state of single radio CSMA meshes in say 2005 and make a list of subjects to read on, then do that. There's a lot of stuff that happened later but in the early 2000s many people tried to make meshes out of 802.11b IBSS and a lot got written about those efforts.
having read that meshtastic section: I mostly agree with their requests tbh. the only suggestions in there seem to be "use full duplex" (with approximately one reason why, though it's a good one) and "solve frequency discovery with SDR" which they've already addressed as somewhat ridiculous - because it is, for someone interested in a low power and low cost network.
particularly the SDR stuff, which is the VAST majority of that section. this is not at all the same target audience as meshtastic:
>A computer with “sufficient” compute power and RAM, to run the ka9q-radio software. KA9Q has stated that a Raspberry Pi 4 is sufficient, and now we have the Raspberry Pi 5 with up to 16 GB of RAM, for only $120.
that's like suggesting the way to fix a wireless problem is to use a wire. otherwise the criticism seems to summarize as "it's slow and bad" and well. okay? that's hardly constructive, whether or not it's accurate.
the whole thing reads like "the solution is left as an exercise to the reader ;)" because it sounds like it's written by and for people who are already experts and just want to read a cathartic list of flaws they already know. and/or "buy better hardware lol". it's not at all the logical slam-dunk that you seem to think it is.
I've been spending a lot of time experimenting with and learning about Meshtastic and MeshCore recently,[0] and I'm also puzzled by the criticism of Meshtastic.
In the article you linked, there are three paragraphs about Meshtastic in a 150-paragraph newsletter about several topics. The criticism seems to be that they they use digipeating, and then it refers to a Fedi thread[1] which is more coherent but still fairly vague. The upshot seems to be that flood routing doesn't scale, which is a fair criticism but feels disproportionate to the level of vitriol against the project.
The Fedi thread also adds that the Meshtastic founders were rude or unprofessional to him but doesn't cite any specifics or evidence.
I see this a lot with Meshtastic. People keep saying the founders are toxic and disrespectful of the community but it's always in these vague terms so I don't know what's driving it.
But specifically in this thread, I agree with sibling poster that you're being disrespectful and arguing ineffectively by pointing to such poor resources and then blaming other people for being unconvinced or confused.
As I understand it, the section on "what not to do" features many things that Meshtastic does, though it does not say that explicitly. Perhaps the linked post wasn't clear to non hams (it is a newsletter targeted at hams), but the biggest issue is not flood routing, but using the same channel for networking and user access. It, by definition, cannot scale meaningfully. Many commercial networks solve this with either FDMA or TDMA.
Elsewhere in the newsletter, the author advocates for a form of FDMA, where users operate on different, dynamically allocated frequencies and all of them are received at once. P25 trunked radios used by almost all law enforcement in the US operate on a system like this.
I think the vitriol from those who are in the space either professionally or as an amateur comes from the fact Meshtastic is repeating mistakes we knew about in the 80s at the latest, for which reams if literature freely exists.
That's a reasonable take to an extent, but underlying all of that is the assumption that Meshtastic should be trying to scale up to support hundreds or thousands of active nodes on a single mesh. Since that's clearly almost impossible to achieve with an ad-hoc network of low-power LoRa radios, it's not entirely fair to criticize Meshtastic for not inventing a revolutionary solution to a very hard problem.
It would be more fair to criticize Meshtastic for not being clear enough about the tradeoffs and limitations inherent in a low-speed ad-hoc mesh network, and for not actively encouraging people to seek other hardware and software if their use cases are not well-matched to what Meshtastic hardware is capable of. A one size fits all solution simply isn't possible, and Meshtastic can't be the right answer for everyone.
This is also a fair response, however I'd argue that the current architecture, far from supporting hundreds or thousands, won't even support dozens in a small area with meaningful traffic being exchanged (e.g., not just heartbeats and routing data). The solutions exist and no revolutionary approach is needed. That's the crux of the complaints.
Now, for the hobbyist these solutions are harder to implement and that's not nothing, but I don't even see a movement to switch over to something more robust.
> Now, for the hobbyist these solutions are harder to implement and that's not nothing,
I'd argue it's everything. A network architecture that requires serious fixed infrastructure should probably be an entirely separate project from the ad-hoc mesh formed solely by cheap battery-powered portable/handheld gadgets. And everyone should be realistic about what "meaningful traffic" is for a network with a default data rate of ~1kbps; it's not reasonable to expect that to support the kind of chatter a busy IRC server would see.
Have YOU ever tried interacting with the developers? No?
* They made incredibly poorly designed software — the firmware and the mobile apps — and then yell at you for “using it wrong”
* The refuse to admit they made a mistake with the 7 hop limit and call you an idiot for not believing in their garbage “simulator”
* They write nasty responses to app reviews and GitHub issues because they’re petulant children. Just go read the responses, and look at the hissyfit the of the primary app developer in discord.
* They’ve taken down multiple community groups because they decided they needed to be a business rather than an open-source project. Seriously just go look at the history in their discord #trademark channel. They’re on the verge of evil.
All this stuff is available and just because YOU choose to put your head in the sand doesn’t mean it didn’t happen.
Like all "economically sound" ideas, people fuck it up. To the drivers, its one more reminder of a government taxing you on a day to day basis, locking up the roads taxes paid for, for another series of taxes.
Chicago is the poster child here. Constant rate hikes. Diverted funds meant to maintain the roads going elsewhere. "Temporary" tolls that become "permanent", etc.
With a side of handing off management and a slice of the revenue to private entities. With minimum revenue guarantees that then act as a disincentive to improving nearby roadways.
If you look at water usage in Nevada, 75% of it goes to agriculture [1]. Agriculture provides a lot of jobs and food. Unfortunately the resources are no longer there. You can eliminate landscaping (yards, golf courses, las vegas fountains, etc), but it still won't make a dent in the water use.
It's not just Nevada, but Nevada is the poster child here for everything that's gone wrong with water use.
So something's gotta give. And it turns out that farming in deserts may not have been the best use of the land (or water).
The Desert Land Act under which a lot of desert land was claimed (and, the only remaining way I know of state land can still privately be claimed) only gave it to you if you established irrigation and agriculture.
The government basically asked for it, and then made it the only way to get much of the land. And now of course, many heads in government now complaining about the evil private land owner who did the thing the government asked for and precondition.
Yay, they own the land. A hundred plus years later, I don't see why the descendants (or corporate owner) should have the same water rights now after things have changed. Don't strip them of the land...but something has to give.
Yes that could be done via eminent domain of their water rights. The only note would be that since the value of especially the more rural desert land is tied almost completely to acreage times water rights per acre, it's basically a full buyout of the entire non-residential rural desert due to the takings clause. I don't know how much it'll cost, but it will be a lot.
>A hundred plus years later
I know of people still investing large sums today to claim under the Desert Land Act. It's still active. They need to establish irrigation and usually drill/share a well (maybe hauling could work but you have to show it's economically viable), and establish that over a multi year proof process the viability of the land. Just harder than it used to be. So to be clear it might be someone from yesterday, although it's just less common. I'm not sure if the takings clause would cover them though, as they don't technically own it until the proof process is complete, so for them it'd probably merely just be a total loss.
The takings issue is why I believe that rather than invoking eminent domain, the CA government should institute a Uniform Water Use Tax, whose aim is to establish a single price for any use of water (charged per gallon/acre foot) in the state. The cost of acquiring the water used can then be claimed as a credit against the Uniform Water Use Tax.
This respects water rights while aligning incentives to conserve water and as a bonus establishes a more even playing field in the agricultural sector, enhancing competition and reducing the unjust profits of the Resnicks' shady water empire.
Is that actually taken into account in a taking? I haven’t thought about this stuff in decades, and I know there is some weirdness with regulatory takings.
Another way to frame the question: if the government just changes the water rights per acre, does that itself trigger the takings clause?
It depends on the type of water right (there are many kinds). The State has the ability to effectively recall some water rights. True titled rights would be a taking.
Nevada gets 4% of the water in the first place. Almost all of that 4% goes to Ag and mining as you said. The things people use as "the poster child" like fountains and golf courses are rounding errors.
Like 60-75% of all ag land in the US is to grow feed for cows. Mostly in dry environments. This is because the old water rights were distributed on a "use it or lose it" basis which encourages wasteful use.
In some desert areas there is no other use for the water because the aquifers are fragmented. People don't live there, you can't readily move the water to somewhere useful, and it won't flow anywhere useful on its own. Agriculture is a way to convert water into something easily transported.
This doesn't apply to many places but in the desert Mountain West this is often the case. Also, while it may seem surprising, a few crops really thrive in the high desert e.g. onions.
This is absolutely not the case when it comes to Nevada agriculture. They're moving water in from outside the state to feed ag for places where people do live.
Rust isn't so much "competing" as it is "complimentary" to python. This is very much how python was billed originally as a scripting language for "C" in it's early days.
The slow parts of your python program can be rewritten in rust or C, your choice. So refreshing.
I found myself traveling recently and missed my 3d printer. There were a few neat things I could have done if I had a printer in a carry on. It would be kinda awesome to have a self contained 3d printer with a battery to take wherever I go.
If you're near a harbor freight, they have cheap rugged cases. Maybe design around that form factor, since they're easy to get?
I have a couple idea's on how I wanted to do it:
- Belt printer fitted into a briefcase (the harbor freight case form factor would be good for that!)
- Positron style
- Maybe mess around with double four-bars
Making it self-contained with a battery is also a really cool concept I'll have to explore!
May not meet your particular definition of small, but my portable printer is a Voron 0.2. The frame is sturdy enough that you can attach a handle to one corner and just carry it around with you, at least for a while. It's not particularly lightweight. But it is small (fits completely inside the build volume of my other printer), and being fully enclosed within the frame, seems more durable than the likes of the other tiny printers (Lemontron, A1 Mini, etc.)
You'd need a pretty substantial battery on account of how much heat it takes to melt filament. Even the Bambu A1 Mini uses ~150W while heating the hot end. I like the idea of a portable printer, though.
It's actually not the hotend heating that's the largest power drain, it's heating the large heat bed. Bambu Lab is introducing firmware features to more slowly ramp up the heat, but I don't need if that could happen slowly enough to not drain a battery.
Here's an example of a good criticism: https://www.zeroretries.org/p/zero-retries-0215
I have no experience with the community, but if they couldn't have been bothered with understanding AlohaNet from several decades previous, than maybe it's not surprising.
I myself have been fairly critical of meshtastic, you can probably search for bb88 and meshtastic to find more criticisms.
To save you some time, I live in a fairly populous city with a bunch of meshtastic nodes, and can't get a message accross from me to my friend who lives one hop away.
reply