Philosophize all you want; if the first instruction in your manual is 'pip install' I don't consider you to be anywhere near as offline / off-grid as you claim to be. All the Lora mesh projects do this. For all the off-grid advertising they do, there doesn't seem to be a lot of thought put into bootstrapping or maintaining the network once the internet is gone. (yes, you and I could probably figure it out, but some user who actually needs this might not be able to). I'm not really complaining about this, but it is a little ironic.
Reticulum is actually ahead of the curve by having a ready to use PDF manual you can download. For my part, I've been trying to put together an all-inclusive Raspberry Pi image or a live USB for Meshtastic, but it's not quite there yet (it's no more than a hobby for me, but I'm not making big off-grid promises either).
"The internet no longer exists" is a particularly extreme subset of off-grid scenarios. For the more plausible off-grid scenarios—the ones that have actually happened—the unavailability of the internet has been varying degrees of localized and temporary. In that context, being able to bootstrap the entire network without any reliance on internet infrastructure is more of a convenience than a hard requirement.
In particular, it seems obvious to me that any preparedness plan that requires a user to acquire in advance specialized hardware (eg. a battery/solar-powered long-range radio of some kind) to be used with an off-grid network can reasonably expect that user to also be prepared with the software to drive that hardware.
The whole project is a convenience. If I were in a situation where I actually had to rely on Meshtastic for comms, I'd be pretty nervous. It doesn't really work that well. Luckily, I've only enjoyed Meshtastic recreationally. Where this comes from is from me trying to learn about and set up some nodes on vacation in an area with very limited internet. I followed the tutorials, thought I had what I needed, but I was wrong. Woops, documentation is online. Within the community, I've seen "that same thing happened to me" more than once.
As with many hobbies, this is a "just because I can, I will" type of thing.
What you don't think we can put up a shadow internet running at 250kbps?
That said, I picked up a couple of prebuilt lora solar nodes and a couple of mobile nodes (seed solar jobies and seeed mobile jobies) and stuck the solar ones into my upper story windows just over new years, one is set up as a meshtastic repeater the other as a meshcore repeater.
I'm pretty amazed at the distances I hear from, I'm getting stuff this morning over meshcore all the way from vancouver bc into my office in seattle (pugetnet.org).
To get it all dialed in having a discord full of old HAM guys that know RF pretty well certainly doesn't hurt.
It's certainly hobbiest grade at best. It seems like it could be very interesting for installs in small communities and larger estates for backhaul for remote iot applications. Obviously you aren't going to push video over that bandwidth but for weather stations and the like seems cool.
Reticulum becomes more interesting when you are talking about some of the more robust radio technologies. Building a mesh LAN out of old wifi gear is interesting in concept.
Not only any computer of last resort would have software installed in advance and easily prepared redundant archives to install it again, but "pip install" is perfectly fine for other use cases: testing Reticulum, regularly updating everyday computers, improvised installations on someone else's computer, etc.
Just so I understand, what sort of bootstrap process are you looking for? Even a pre-built binary is going to require a download? If you build from source (e.g., C), you’re going to need to download the source code and a compiler. I’m not much a Python guy myself, but installing via pip doesn’t seem particularly bad. But I’m probably missing your point.
My goal is to be able to do all steps of the typical Meshtastic youtube tutorial without access to the internet.
I like to liken it to my other hobby of retrocomputing. In the old days, your whole OS and all the applications ran from a few floppies and a couple of books for documentation. If you need to duplicate the environment, just make copies of your disks. And of course you need an original set to start with. But nobody thinks of that as "offline", that's just the normal way it works, and yet it seems more offline than modern projects who claim to be offline.
If you’re pip installing you can just toss your venv on a floppy/cd/flash whatever if you’re so inclined. I’m not sure I understand the concern. The need for internet is a sliding scale with your own resourcefulness.
Reticulum and Nomadnet should have been ported to Go long ago; you can bundle all the dependencies
under a zip/tgz file just in case, and provide static binaries for everyone. NNCP, Yggdrasil... every portable project uses sane choices. With Python you need Pip, pinned releases and a beefy machine.
Ha! I believe every RNode can be used to bootstrap a Reticulum network, as that tiny ESP32 hosts the RNode firmware, the full network software stack and documentation! The RNode has the capability to become a Wifi access point, if you connect you get this at 10.0.0.1.:
I’ve looked at a few of the LoRa-based mesh network systems over the last couple months. They all seem to have a philosophical document of some sort, like this one, sometimes buried as part of the user docs, but none of them have clear protocol specification docs. When I look at their node maps, the node counts are absurdly small (like 20 nodes in a city of 1 million people). I suspect each of them has major scaling issues. Sure, mesh networks are great because they are more resilient, but if you trust nobody and you have no sense of a route to a destination, you’re left with flooding as your primary next-hop selection method, which means you’re going to be about as scalable as an old Microsoft LAN Manager network was in 1995 (which is to say not very). Short of reading the code, does any sort of protocol documentation (or better yet, analysis) exist for Reticulum?
> but none of them have clear protocol specification docs
This is a big turn off for me. I have seen it for a number of protocols beyond mesh ones. ESP-Hosted does this too. So does ELRS. Maybe I'm too used to reading data sheets etc, but if your protocol requires a specific implementation, I am put off by the friction: I must integrate your software, in the language you used, and will likely hit compatibility problems as a result.
Exactly. And are you going to break it one day just because and force every node to run the new version of firmware to stay active. I like implementers who show some transparency and some self-reflection about the limits of the protocol. And to be clear, in looking through the other docs in the Reticulum repo, it looks like there are more protocol details there, so maybe Reticulum has that transparency.
Reticulum has no bandwidth management. If your node or the whole local area is flooded with traffic from the rest of the network there is nothing you can do.
"Reticulum does not include source addresses on any packets" and with that you cannot throttle passing-through traffic based on source. Any hope of scaling is gone.
Meshtastic is the most popular in my area. I can see about 150 nodes from my house in a US county of ~300K (though actually being able to talk to most of those remains questionable).
I am certain the popularity of Meshtastic is down to how easy they have made it to onboard. Buy the module, flash using the web flasher, install the app on your phone, done. There's a Youtube tutorial on every street corner for this, even though I (and seemingly many people) don't find Meshtastic to be all that reliable.
To be clear, I’m not harshing on Meshtastic’s node counts. In some sense these systems are like packet ham radio. They appeal to a specific user base. I just question how their protocols are going to scale, and even 150 nodes is extremely small compared to the number of people around you who are using the Internet, WiFi, etc.
So, for instance, at the URL you referenced, it says at the bottom:
> As meshes grow larger and traffic becomes more contentious, the firmware will increase these intervals. This is in addition to duty cycle, channel, and air-time utilization throttling.
> Starting with version 2.4.0, the firmware will scale back Telemetry, Position, and other ancillary port traffic for meshes larger than 40 nodes (nodes seen in the past 2 hours) using the following algorithm:
> For example an active mesh of 62 nodes would scale back telemetry.device_update_interval to 79.5 minutes instead of the 30 minute default.
It looks like they are already building back-off strategies as the net scales, and that starts to happen at very low node counts (just 40). So, what happens when node counts hit 500 or 1000? Again, not trying to throw stones; just trying to understand how far these protocols can go and how they degrade/fail as they scale. Ideally, they don’t fall over and even possibly get more robust (with more nodes, there are typically more topological connections between nodes, which provides more possible paths and resiliency).
Reticulum is absolutely not flood routed and is not "LoRa-based" lmao. Typical hn comment.
Planetary-scale networks is mentioned as a design goal on the first page of the docs https://reticulum.network/ which are hidden at the very top of the git repo.
Okay, maybe Reticulum isn’t strictly LoRa-based, but others are (e.g. Meshtastic), and while Reticulum works over lots of physical layers, the README specifically states “An open-source LoRa-based interface called RNode has been designed specifically for use with Reticulum.”
Exactly. Okay, that’s a great claim. How? Also, “planetary scale” is meaningless. With the right node count (low), topology, and radios, just about any mesh network can achieve “planetary scale.” But that doesn’t mean it’ll support 10 thousand users, never mind millions. There are underlying technical reasons that the Internet works the way it does.
Sure, but The Zen of Reticulum repeatedly says that all that centralized infrastructure is bad, bad, bad. So, it seems a bit like cheating if you still need all that to scale.
> The internet we rely on today is a chain of single points of failure. Cut the undersea cable, and a continent goes dark. Shut down the power grid, and the cloud evaporates. Deprioritize the "wrong" traffic, and the flow of information is strangled.
The deep brokenness of the current internet, specifically what has become the "cloud" is something I've been thinking about a lot over the past few years. (now I'm working on trying to solve some of this - well, at least build alternatives for people).
and this:
> The way you build a system determines how it will be used. If you build a system optimized for mass surveillance, you will get a panopticon. If you build a system optimized for centralized control, you will get a dictatorship. If you build a system optimized for extraction, you will get a parasite.
Seems to be implying (as well as in other places) that this was all coordinated or planned in some way, but I've looked into how it came to be this way and I grew up with it, and for me, I think a lot of it stemmed from good intentions (the ethos that information should be free, etc.)
I made a short video recently on how we got to a centralized and broken internet, so here's a shameless plug if anyone is interested: https://youtu.be/4fYSTvOPHQs
But the part about the undersea cable is simply wrong! Major undersea cables have been disrupted several times and never has a "continent gone dark".
I think this betrays a severe misunderstanding of what the internet is. It is the most resilient computer network by a long shot, far more so than any of these toy meshes. For starters, none of them even manage to make any intercontinental connections except when themselves using the internet as their substrate.
Now of course, if you put all your stuff in a single organization's "cloud", you don't get to benefit from all that resilience. That sort of fragile architecture is rightly criticized but this falls flat as a criticism of the internet itself.
People naturally want to maximize the value they extract from any system.
If you hand individuals or groups the internet, they will naturally use it for spam, advertisement, scams, information harvesting, propaganda, etc - because those are what gain them the most.
The 'enshittification' if the internet was inevitable the moment it came into existence, and is the result of the decision of its users just as much as any one central authority.
If you let people communicate with each other on a large scale at high speeds, that's what you get.
The only way to avoid the problem is to make a system that has some combination of the following:
* No one uses
* Is slow
* Is cumbersome to use
* Has significant barriers to entry
* Is feature-poor
In a such a system, there's little incentive to have the same bad behaviors.
We'd probably agree on this: people respond to incentives created by system design. One example that comes to mind is how London's Congestion Charge and how it has changed traffic behavior over the years depending on how the rules change.
There is nothing inherent about fast, large-scale, or user-friendly communication that forces spam, scams, or propaganda. Its just that those outcomes emerge when things like engagement, attention, or "reach" are rewarded without being aligned to quality, truth, or mutual cooperation.
This is a well-studied problem in economics, but also behavioral science and psychology: change the incentive and feedback structure, and behavior reliably changes.
Based on the studies I've read in and around this topic, I think harmful dynamics are not inevitable properties of communication, but really contingent on how each system rewards actions taken by participants. The solution is not slowness or barriers, but better incentive alignment and feedback loops.
I would argue that it's not the systems of the internet that are the problem. The problem is the other structures (governmental, economic, etc.), which have bad incentives, which leads to using tools like the internet in a negative way. If it wasn't the internet, it would simply be whatever other form of communication was available. But the Internet's enormous speed and reach make it especially susceptible/tempting for those kind of behaviors.
Not sure I follow the allegory, could you substantiate?
I'm not sure specifically e.g. why being an engineer would put someone at an outsized disadvantage against the already hopeless notion of "understanding how the world works [in its totality?]".
One would think being smart and educated would put them ahead of the pack, even if they overestimate how smart and educated they are compared to others, or fall victim to the consequences of that - an accusation engineers commonly recieve on social media, with similarly high suggestiveness, and similarly little substantiation.
If creative people don’t think at a systems level or a political intersectional level when doing design then they will completely ignore or miss the fact that engineering is a subset of a political or otherwise organizational goal
The key problem with most engineers is that they don’t believe that they live inside a political system
I think that's an important consideration, especially with telecommunications technologies, but the author seems to have been pretty mindful of that angle from the get go, i.e. they seem to have been frustrated with the state of affairs from the beginning.
Or do you mean that to you it all reads as yet another case of someone thinking their technology is what's going to right the ship that is society's current trajectory, then bailed when that didn't come to be? Cause while I can certainly see that being the case, I'd say such a cycle is as much desperation as it it naivety. I think this is even reflected in it being a PHY-agnostic thing, meaning as far as an effort into anything goes, it's a fairly enduring one.
> Or do you mean that to you it all reads as yet another case of someone thinking their technology is what's going to right the ship that is society's current trajectory, then bailed when that didn't come to be?
Couldn’t have said it better myself
Desperation is just a manifestation of manic ignorance unfortunately
The only solution to ignorance is education and I’ll go back to my original point which is this precise thing was discussed over and over and in detail over the last half century of computing in multiple places
Most notably one of the most popular well distributed books that discusses this explicitly is Rodney Brooks’ mythical man month
So my original critique is that engineers do not even utilize the core literature for which there is global consensus on these problems
How would desperation be "manic ignorance", when desperation is specifically when you think/know something is unlikely to impossible, yet feel cornered enough to go for it anyways? The only interpretation I can imagine that fits, you clearly did not mean.
This really just reads like finding their efforts unreasonable, then presenting that opinion as a foregone logical conclusion they were merely too stupid / ignorant to realize, and doing so from a position of hindsight with zero evidence no less. It's purely just tropes and ideas. And even if we keep to just reasoning about ideas, if technology was not able to shape society, politics, or the way people interact, we ourselves wouldn't be talking, so I beg to differ on it being such a foregone conclusion in general.
If I really had to consider a critique along these lines, the only salient difference I see specifically to ventures like this is that they concern themselves very little with what there's a cultural moment and narrative space for, due to being convinced whatever they're doing needs to happen. Ventures need these though, hard work and a sound idea is not sufficient (or sometimes even required), just like with anything else. It needs to find and retain an audience, and have that scale. Same for purely political ventures, really. Opportunity, luck, commitment, and capability is what takes the win. This project, and ones similar, do provide at least the last one for those coming later.
It's Fred Brooks by the way, and the book is about project management deadlines vs staffing strategies according to the synopses I found. I continue to fail to find the connection between that and this. Conversely, the proverbial law usually mentioned in relation with the book is Brooks' law, not Conway's. Not sure if that was a mistake or intentional.
Too bad the Zen of Reticulum is against freedom. Specifically freedom 0: the freedom to use the software for any purpose. Its restrictions preventing it "from being used in systems designed to harm humans" prevents it from being used in e.g. militia groups in oppressed countries who may wish to use it to harm humans in self-defense.
A) In self-defense, you don't intend to harm humans, but are only doing so when it's down to your life or theirs. So such a system could be argued to not be designed to harm humans, but instead preserve your own life.
B) In any case, I'm OK with it. Having the software explicitly licensed like this may prevent it from being legally considered a terrorism tool or munition if a bad actor were to be found connected with it, and if that happens, that's going to have much more freedom-restricting consequences with respect to the software.
Thank you very much! I also feel that the impact of software licensing on violent groups behavior might be low.
It is, however, interesting on principle, since it only allows the use by criminals (implicitly), and not by law enforcement. By then making the tool very impractical to use, we can punish bad actors still.
(I think there was a honeypot operation to this effect, something with feds making up a "secure encrypted phone" and then acquiring Cartels as a major customer.)
(On the off chance I just burned this very similar operation: dear feds, I'm so sorry!)
The comment that started this thread is as follows:
> Too bad the Zen of Reticulum is against freedom. Specifically freedom 0: the freedom to use the software for any purpose. Its restrictions preventing it "from being used in systems designed to harm humans" [...]
So if you're a lawful good human-harming person, you are prohibited from using Reticulum by this Zen document.
If, however, you're an unlawful kind of human-harming person, then you likely don't feel the pressure from the Zen document to stop using Reticulum.
(And surely you can't flip the logic like you did right there: "engineers are implicitly allowed to use X" doesn't convert to "users of X are implicitly engineers".)
So no, I'm saying that of all users intending to cause humans harm with this tech, only criminals are permitted (or at least, aren't meaningfully restricted) to use Reticulum. Only in this niche case.
Yep. People wanting to do the right thing and prepare at scale for self-defense won't violate the license but the people it intends to restrict will, because they don't care.
It's such a strange and unfortunate addition to the project. Also, what's the point of assuming every entity is potentially hostile? Can't you just put in the license "you're not allowed to be malicious or hostile on this network"?
GP used intentionally hostile and weird interpretation of "if you intend to subdue, enslave or kill, don't use it", aimed at dictatorships, organisations like Palantir, etc.
What? If I'm in a militia group that resists oppressive governments, I intend to kill people. Therefore I'm not allowed to use Reticulum to coordinate with my mates, even though most people would agree that I'm not killing immorally.
> even though most people would agree that I'm not killing immorally.
They’d only agree in the abstract. As soon as you name the oppressive regime you’re fighting against, suddenly a huge chunk of those people will come up with reasons to no longer support you.
And just because e.g. AI companies violate copyright to train their models and get away with it, doesn't make it right. The same principle applies here.
The exact text is "The Software shall not be used in any kind of system which includes amongst its functions the ability to purposefully do harm to human beings."
This is an example of the HN "Jump to Conclusions Mat" where there is an instant jump to extremely high level politics and philosophy and skipping over the more practical mundane problems.
A more practical issue is the author has zero interest in being sued if my LoRA connected emergency stop button for my CNC milling machine crashes and the machine then hurts someone (possibly myself).
Or my "emergency alert" transponder fails when I'm in the wilderness and someone (maybe me) dies instead of being rescued.
The wildest part of the story which isn't being covered is this is an example of one guy doing all the work to produce something more capable than the entire meshtastic project in about a year. A real life example of 10x or 100x engineers. How can meshtastic accomplish so little if one guy accomplished so much? Historically it was not THAT bad where having more than one person work on a network protocol never killed progress for decnet or banyan vines or SNA or any other old time protocol, but maybe its a mesh network thing that having more than one cook in the kitchen eliminates all progress.
Unfortunately, being a pretty much 1 person project he doesn't have the legal skills to realize the license as written is awful and needs rewriting to achieve his goals, assuming his goals are even a good idea...
I've set this up and used it on my LAN at home. Its a LOT more than just LoRA or just meshtastic and its pretty cool and works well. The app on my phone works well. Being abandonware I'm shutting it down "when I get around to it". The ratio of Meshcore to Meshtastic users/traffic is around 20:1 in my area so I'll be setting up Meshcore to fit in. Mesh LoRA is very local just like cell phone service; I'm well aware there are parts of the world operating at an opposite ratio of popularity where you "have to" use meshtastic to fit in. That is not where I live so I must use meshcore.
Meshtastic isn't used here, so I can't mesh so cross that off. Reticulum works perfectly and is abandonware so cross that off. Meshcore has its ... interesting pay money to unlock features scheme, I can't decide if I like or dislike that, I'd like to cross that off but its the only remaining protocol. I could write my own and GPLv2 it but if a superior system (reticulum) can't get buy in, my better licensed system would also be unused. I think I am stuck having to use Meshcore, I about 95% like that and 5% dislike that.
I do find it amusing that I used ham radio AX.25 packet radio in the late 80s, early 90s, some times this century, I know all about digipeating problems and hidden transmitter problems and all the stuff the "kids" refuse to do a literature search for and seem surprised when it bites them. Really this mesh stuff is just ham packet radio from 1981 except the total cost of a station is like $15 vs back in the day it was oh at least $1000. I had a node running linux AX25 back in the 90s and I'm sure I had a couple thousand bucks in equipment by the time I was done, mostly repurposed later on. I still have several hardware TNCs in some closet or shelf somewhere...
> A more practical issue is the author has zero interest in being sued if my LoRA connected emergency stop button for my CNC milling machine crashes and the machine then hurts someone (possibly myself).
Don't most actual free software licenses include a warranty disclaimer? So said military would have no grounds to sue, since there's no warranty or guarantee of function provided.
Thing is, I want to like Reticulum. It's a great protocol, way better than Meshtastic. It has a great vision. IMO it's not abandonware (yet) but even if it was, I'd probably be willing to maintain it for myself. I just wish it was FOSS.
> The mental maps we carry are dominated by a single, misleading image: The Cloud.
> To break free of the center, you must also let go of the concept of the "Address".
When I was still dealing primarily with on-prem networks in regulated environments (or cloud networks stubbornly architected in a fashion similar to on-prem ones) I worked with a lot of people that could not and would not ever understand this. It's not just a cloud thing. Some people just cling to using IP addresses for everything all the time. They don't understand why trying to access the JIRA server via IP wouldn't work because they didn't understand SNI let alone a Host Header. Dynamic record registration and default suffix settings are nothing more than a section of settings to be cruised over during clicked-in configuration. Zones can and should be split without regard for architecture or usage. Et cetera.
My theory is that because these people didn't understand Layer 7 stuff like HTTP or DNS they just fall back to what they can look at in a console (Cisco ASA, AWS, or otherwise). IPv6 will simplify a lot of the NAT stuff but it won't cure these people of using network addresses as a crutch. Not really sure what the systemic solution is - I was like this once but was fortunate enough to be task with migrating a set of BIND servers to the cloud and so learned DNS by the seat of my pants. Maybe certification exams should emphasize this aspect of networking more.
I love that Mark Qvist publishes his strong opinion, view of the world, and goals.
It quite smells like the hacker spirit of the 80s, mixed with a little spiritualism and anarchism. Very refreshing after so many other people are just disillusioned, worn out, angry, or frightened.
Not much "Zen" when it barely works under i386 (Atom n270 CPU), 1GB of RAM and a simple 80x25 terminal. Sadly, even my usual one (100x32/36) isn't good enough to please retrowannabe hipsters.
i see this project more of a high security deployment. a sort of red phone network. in a post apocalypse scenario, we can do open networks on lora, plus at that time, we gonna need text manuals for agro, fabrication etc... essentially survival wikis.
At some point we will be so tired of distinguishing between AI generated content and human content that we will stop using the Internet and it will be left to bots.
Philosophize all you want; if the first instruction in your manual is 'pip install' I don't consider you to be anywhere near as offline / off-grid as you claim to be. All the Lora mesh projects do this. For all the off-grid advertising they do, there doesn't seem to be a lot of thought put into bootstrapping or maintaining the network once the internet is gone. (yes, you and I could probably figure it out, but some user who actually needs this might not be able to). I'm not really complaining about this, but it is a little ironic.
Reticulum is actually ahead of the curve by having a ready to use PDF manual you can download. For my part, I've been trying to put together an all-inclusive Raspberry Pi image or a live USB for Meshtastic, but it's not quite there yet (it's no more than a hobby for me, but I'm not making big off-grid promises either).
"The internet no longer exists" is a particularly extreme subset of off-grid scenarios. For the more plausible off-grid scenarios—the ones that have actually happened—the unavailability of the internet has been varying degrees of localized and temporary. In that context, being able to bootstrap the entire network without any reliance on internet infrastructure is more of a convenience than a hard requirement.
In particular, it seems obvious to me that any preparedness plan that requires a user to acquire in advance specialized hardware (eg. a battery/solar-powered long-range radio of some kind) to be used with an off-grid network can reasonably expect that user to also be prepared with the software to drive that hardware.
The whole project is a convenience. If I were in a situation where I actually had to rely on Meshtastic for comms, I'd be pretty nervous. It doesn't really work that well. Luckily, I've only enjoyed Meshtastic recreationally. Where this comes from is from me trying to learn about and set up some nodes on vacation in an area with very limited internet. I followed the tutorials, thought I had what I needed, but I was wrong. Woops, documentation is online. Within the community, I've seen "that same thing happened to me" more than once.
As with many hobbies, this is a "just because I can, I will" type of thing.
What you don't think we can put up a shadow internet running at 250kbps?
That said, I picked up a couple of prebuilt lora solar nodes and a couple of mobile nodes (seed solar jobies and seeed mobile jobies) and stuck the solar ones into my upper story windows just over new years, one is set up as a meshtastic repeater the other as a meshcore repeater.
I'm pretty amazed at the distances I hear from, I'm getting stuff this morning over meshcore all the way from vancouver bc into my office in seattle (pugetnet.org).
To get it all dialed in having a discord full of old HAM guys that know RF pretty well certainly doesn't hurt.
It's certainly hobbiest grade at best. It seems like it could be very interesting for installs in small communities and larger estates for backhaul for remote iot applications. Obviously you aren't going to push video over that bandwidth but for weather stations and the like seems cool.
Reticulum becomes more interesting when you are talking about some of the more robust radio technologies. Building a mesh LAN out of old wifi gear is interesting in concept.
Not only any computer of last resort would have software installed in advance and easily prepared redundant archives to install it again, but "pip install" is perfectly fine for other use cases: testing Reticulum, regularly updating everyday computers, improvised installations on someone else's computer, etc.
If you can't figure out how to store dependencies locally you shouldn't be operating a network so everything kind of balances itself out.
Just so I understand, what sort of bootstrap process are you looking for? Even a pre-built binary is going to require a download? If you build from source (e.g., C), you’re going to need to download the source code and a compiler. I’m not much a Python guy myself, but installing via pip doesn’t seem particularly bad. But I’m probably missing your point.
My goal is to be able to do all steps of the typical Meshtastic youtube tutorial without access to the internet.
I like to liken it to my other hobby of retrocomputing. In the old days, your whole OS and all the applications ran from a few floppies and a couple of books for documentation. If you need to duplicate the environment, just make copies of your disks. And of course you need an original set to start with. But nobody thinks of that as "offline", that's just the normal way it works, and yet it seems more offline than modern projects who claim to be offline.
If you’re pip installing you can just toss your venv on a floppy/cd/flash whatever if you’re so inclined. I’m not sure I understand the concern. The need for internet is a sliding scale with your own resourcefulness.
Reticulum and Nomadnet should have been ported to Go long ago; you can bundle all the dependencies under a zip/tgz file just in case, and provide static binaries for everyone. NNCP, Yggdrasil... every portable project uses sane choices. With Python you need Pip, pinned releases and a beefy machine.
Ha! I believe every RNode can be used to bootstrap a Reticulum network, as that tiny ESP32 hosts the RNode firmware, the full network software stack and documentation! The RNode has the capability to become a Wifi access point, if you connect you get this at 10.0.0.1.:
https://unsigned.io/rnode_bootstrap_console/
Shit's insanely well thought out! I encourage everyone to dive in a bit. It's pure tech porn. (If you can endure the occasional Ayn Rand quote lol.)
This is excellent and should be featured more prominently!
I’ve looked at a few of the LoRa-based mesh network systems over the last couple months. They all seem to have a philosophical document of some sort, like this one, sometimes buried as part of the user docs, but none of them have clear protocol specification docs. When I look at their node maps, the node counts are absurdly small (like 20 nodes in a city of 1 million people). I suspect each of them has major scaling issues. Sure, mesh networks are great because they are more resilient, but if you trust nobody and you have no sense of a route to a destination, you’re left with flooding as your primary next-hop selection method, which means you’re going to be about as scalable as an old Microsoft LAN Manager network was in 1995 (which is to say not very). Short of reading the code, does any sort of protocol documentation (or better yet, analysis) exist for Reticulum?
Edit: looks like the Reticulum Manual might have some more technical details. https://github.com/markqvist/Reticulum/blob/master/docs/Reti...
> but none of them have clear protocol specification docs
This is a big turn off for me. I have seen it for a number of protocols beyond mesh ones. ESP-Hosted does this too. So does ELRS. Maybe I'm too used to reading data sheets etc, but if your protocol requires a specific implementation, I am put off by the friction: I must integrate your software, in the language you used, and will likely hit compatibility problems as a result.
Exactly. And are you going to break it one day just because and force every node to run the new version of firmware to stay active. I like implementers who show some transparency and some self-reflection about the limits of the protocol. And to be clear, in looking through the other docs in the Reticulum repo, it looks like there are more protocol details there, so maybe Reticulum has that transparency.
Reticulum has no bandwidth management. If your node or the whole local area is flooded with traffic from the rest of the network there is nothing you can do.
"Reticulum does not include source addresses on any packets" and with that you cannot throttle passing-through traffic based on source. Any hope of scaling is gone.
I believe the recommendation would be to use https://reticulum.network/manual/using.html#using-blackhole-... in such scenarios.
Unfortunately that cannot work. You don't know in advance the traffic destination or source.
Meshtastic is the most popular in my area. I can see about 150 nodes from my house in a US county of ~300K (though actually being able to talk to most of those remains questionable).
I am certain the popularity of Meshtastic is down to how easy they have made it to onboard. Buy the module, flash using the web flasher, install the app on your phone, done. There's a Youtube tutorial on every street corner for this, even though I (and seemingly many people) don't find Meshtastic to be all that reliable.
For reference, this is what Meshtastic has to say about their flood-based mesh protocol: https://meshtastic.org/docs/overview/mesh-algo/
To be clear, I’m not harshing on Meshtastic’s node counts. In some sense these systems are like packet ham radio. They appeal to a specific user base. I just question how their protocols are going to scale, and even 150 nodes is extremely small compared to the number of people around you who are using the Internet, WiFi, etc.
So, for instance, at the URL you referenced, it says at the bottom:
> As meshes grow larger and traffic becomes more contentious, the firmware will increase these intervals. This is in addition to duty cycle, channel, and air-time utilization throttling.
> Starting with version 2.4.0, the firmware will scale back Telemetry, Position, and other ancillary port traffic for meshes larger than 40 nodes (nodes seen in the past 2 hours) using the following algorithm:
> ScaledInterval = Interval * (1.0 + ((NumberOfOnlineNodes - 40) * 0.075))
> For example an active mesh of 62 nodes would scale back telemetry.device_update_interval to 79.5 minutes instead of the 30 minute default.
It looks like they are already building back-off strategies as the net scales, and that starts to happen at very low node counts (just 40). So, what happens when node counts hit 500 or 1000? Again, not trying to throw stones; just trying to understand how far these protocols can go and how they degrade/fail as they scale. Ideally, they don’t fall over and even possibly get more robust (with more nodes, there are typically more topological connections between nodes, which provides more possible paths and resiliency).
Seattle is showing >400 nodes for meshcore: https://meshcore.co.uk/map.html
Reticulum is absolutely not flood routed and is not "LoRa-based" lmao. Typical hn comment.
Planetary-scale networks is mentioned as a design goal on the first page of the docs https://reticulum.network/ which are hidden at the very top of the git repo.
Okay, maybe Reticulum isn’t strictly LoRa-based, but others are (e.g. Meshtastic), and while Reticulum works over lots of physical layers, the README specifically states “An open-source LoRa-based interface called RNode has been designed specifically for use with Reticulum.”
Design goals are great. How do they actually achieve it?
Exactly. Okay, that’s a great claim. How? Also, “planetary scale” is meaningless. With the right node count (low), topology, and radios, just about any mesh network can achieve “planetary scale.” But that doesn’t mean it’ll support 10 thousand users, never mind millions. There are underlying technical reasons that the Internet works the way it does.
Not with flood routing.
Yes, you said. You’ve been very helpful in telling us how it doesn’t work.
flood routing works fine locally, from there on use IP to connect the local networks, no need to reinvent the wheel.
Sure, but The Zen of Reticulum repeatedly says that all that centralized infrastructure is bad, bad, bad. So, it seems a bit like cheating if you still need all that to scale.
> The internet we rely on today is a chain of single points of failure. Cut the undersea cable, and a continent goes dark. Shut down the power grid, and the cloud evaporates. Deprioritize the "wrong" traffic, and the flow of information is strangled.
The deep brokenness of the current internet, specifically what has become the "cloud" is something I've been thinking about a lot over the past few years. (now I'm working on trying to solve some of this - well, at least build alternatives for people).
and this:
> The way you build a system determines how it will be used. If you build a system optimized for mass surveillance, you will get a panopticon. If you build a system optimized for centralized control, you will get a dictatorship. If you build a system optimized for extraction, you will get a parasite.
Seems to be implying (as well as in other places) that this was all coordinated or planned in some way, but I've looked into how it came to be this way and I grew up with it, and for me, I think a lot of it stemmed from good intentions (the ethos that information should be free, etc.)
I made a short video recently on how we got to a centralized and broken internet, so here's a shameless plug if anyone is interested: https://youtu.be/4fYSTvOPHQs
But the part about the undersea cable is simply wrong! Major undersea cables have been disrupted several times and never has a "continent gone dark".
I think this betrays a severe misunderstanding of what the internet is. It is the most resilient computer network by a long shot, far more so than any of these toy meshes. For starters, none of them even manage to make any intercontinental connections except when themselves using the internet as their substrate.
Now of course, if you put all your stuff in a single organization's "cloud", you don't get to benefit from all that resilience. That sort of fragile architecture is rightly criticized but this falls flat as a criticism of the internet itself.
People naturally want to maximize the value they extract from any system.
If you hand individuals or groups the internet, they will naturally use it for spam, advertisement, scams, information harvesting, propaganda, etc - because those are what gain them the most.
The 'enshittification' if the internet was inevitable the moment it came into existence, and is the result of the decision of its users just as much as any one central authority.
If you let people communicate with each other on a large scale at high speeds, that's what you get.
The only way to avoid the problem is to make a system that has some combination of the following:
* No one uses
* Is slow
* Is cumbersome to use
* Has significant barriers to entry
* Is feature-poor
In a such a system, there's little incentive to have the same bad behaviors.
We'd probably agree on this: people respond to incentives created by system design. One example that comes to mind is how London's Congestion Charge and how it has changed traffic behavior over the years depending on how the rules change.
There is nothing inherent about fast, large-scale, or user-friendly communication that forces spam, scams, or propaganda. Its just that those outcomes emerge when things like engagement, attention, or "reach" are rewarded without being aligned to quality, truth, or mutual cooperation.
This is a well-studied problem in economics, but also behavioral science and psychology: change the incentive and feedback structure, and behavior reliably changes.
Based on the studies I've read in and around this topic, I think harmful dynamics are not inevitable properties of communication, but really contingent on how each system rewards actions taken by participants. The solution is not slowness or barriers, but better incentive alignment and feedback loops.
I would argue that it's not the systems of the internet that are the problem. The problem is the other structures (governmental, economic, etc.), which have bad incentives, which leads to using tools like the internet in a negative way. If it wasn't the internet, it would simply be whatever other form of communication was available. But the Internet's enormous speed and reach make it especially susceptible/tempting for those kind of behaviors.
The author discovered Conways law and got frustrated
Too bad nobody wrote a book called “the mythical man month” to dispel the majority of fantasies that engineers have about the way the world works
Not sure I follow the allegory, could you substantiate?
I'm not sure specifically e.g. why being an engineer would put someone at an outsized disadvantage against the already hopeless notion of "understanding how the world works [in its totality?]".
One would think being smart and educated would put them ahead of the pack, even if they overestimate how smart and educated they are compared to others, or fall victim to the consequences of that - an accusation engineers commonly recieve on social media, with similarly high suggestiveness, and similarly little substantiation.
Sure
If creative people don’t think at a systems level or a political intersectional level when doing design then they will completely ignore or miss the fact that engineering is a subset of a political or otherwise organizational goal
The key problem with most engineers is that they don’t believe that they live inside a political system
I think that's an important consideration, especially with telecommunications technologies, but the author seems to have been pretty mindful of that angle from the get go, i.e. they seem to have been frustrated with the state of affairs from the beginning.
Or do you mean that to you it all reads as yet another case of someone thinking their technology is what's going to right the ship that is society's current trajectory, then bailed when that didn't come to be? Cause while I can certainly see that being the case, I'd say such a cycle is as much desperation as it it naivety. I think this is even reflected in it being a PHY-agnostic thing, meaning as far as an effort into anything goes, it's a fairly enduring one.
> Or do you mean that to you it all reads as yet another case of someone thinking their technology is what's going to right the ship that is society's current trajectory, then bailed when that didn't come to be?
Couldn’t have said it better myself
Desperation is just a manifestation of manic ignorance unfortunately
The only solution to ignorance is education and I’ll go back to my original point which is this precise thing was discussed over and over and in detail over the last half century of computing in multiple places
Most notably one of the most popular well distributed books that discusses this explicitly is Rodney Brooks’ mythical man month
So my original critique is that engineers do not even utilize the core literature for which there is global consensus on these problems
How would desperation be "manic ignorance", when desperation is specifically when you think/know something is unlikely to impossible, yet feel cornered enough to go for it anyways? The only interpretation I can imagine that fits, you clearly did not mean.
This really just reads like finding their efforts unreasonable, then presenting that opinion as a foregone logical conclusion they were merely too stupid / ignorant to realize, and doing so from a position of hindsight with zero evidence no less. It's purely just tropes and ideas. And even if we keep to just reasoning about ideas, if technology was not able to shape society, politics, or the way people interact, we ourselves wouldn't be talking, so I beg to differ on it being such a foregone conclusion in general.
If I really had to consider a critique along these lines, the only salient difference I see specifically to ventures like this is that they concern themselves very little with what there's a cultural moment and narrative space for, due to being convinced whatever they're doing needs to happen. Ventures need these though, hard work and a sound idea is not sufficient (or sometimes even required), just like with anything else. It needs to find and retain an audience, and have that scale. Same for purely political ventures, really. Opportunity, luck, commitment, and capability is what takes the win. This project, and ones similar, do provide at least the last one for those coming later.
It's Fred Brooks by the way, and the book is about project management deadlines vs staffing strategies according to the synopses I found. I continue to fail to find the connection between that and this. Conversely, the proverbial law usually mentioned in relation with the book is Brooks' law, not Conway's. Not sure if that was a mistake or intentional.
Too bad the Zen of Reticulum is against freedom. Specifically freedom 0: the freedom to use the software for any purpose. Its restrictions preventing it "from being used in systems designed to harm humans" prevents it from being used in e.g. militia groups in oppressed countries who may wish to use it to harm humans in self-defense.
A) In self-defense, you don't intend to harm humans, but are only doing so when it's down to your life or theirs. So such a system could be argued to not be designed to harm humans, but instead preserve your own life.
B) In any case, I'm OK with it. Having the software explicitly licensed like this may prevent it from being legally considered a terrorism tool or munition if a bad actor were to be found connected with it, and if that happens, that's going to have much more freedom-restricting consequences with respect to the software.
>Willing to kill.
>Not willing to violate the license of a software package.
Thank you very much! I also feel that the impact of software licensing on violent groups behavior might be low.
It is, however, interesting on principle, since it only allows the use by criminals (implicitly), and not by law enforcement. By then making the tool very impractical to use, we can punish bad actors still.
(I think there was a honeypot operation to this effect, something with feds making up a "secure encrypted phone" and then acquiring Cartels as a major customer.)
(On the off chance I just burned this very similar operation: dear feds, I'm so sorry!)
Did you really say that only criminals are permitted to use Reticulum?
So presumably, by the extension of your argument, average person using Reticulum is either ("implicitly") a criminal or breaking the licence / ToS.
Where do you see it?
The comment that started this thread is as follows:
> Too bad the Zen of Reticulum is against freedom. Specifically freedom 0: the freedom to use the software for any purpose. Its restrictions preventing it "from being used in systems designed to harm humans" [...]
So if you're a lawful good human-harming person, you are prohibited from using Reticulum by this Zen document.
If, however, you're an unlawful kind of human-harming person, then you likely don't feel the pressure from the Zen document to stop using Reticulum.
(And surely you can't flip the logic like you did right there: "engineers are implicitly allowed to use X" doesn't convert to "users of X are implicitly engineers".)
So no, I'm saying that of all users intending to cause humans harm with this tech, only criminals are permitted (or at least, aren't meaningfully restricted) to use Reticulum. Only in this niche case.
I'm sure such militias wouldn't worry about the ToS.
However there's a chance apartheid and authoritarian countries would not use it exactly because of this.
> However there's a chance apartheid and authoritarian countries would not use it exactly because of this.
I don't think they will care.
Yep. People wanting to do the right thing and prepare at scale for self-defense won't violate the license but the people it intends to restrict will, because they don't care.
It's such a strange and unfortunate addition to the project. Also, what's the point of assuming every entity is potentially hostile? Can't you just put in the license "you're not allowed to be malicious or hostile on this network"?
Just read the manifest.
GP used intentionally hostile and weird interpretation of "if you intend to subdue, enslave or kill, don't use it", aimed at dictatorships, organisations like Palantir, etc.
What? If I'm in a militia group that resists oppressive governments, I intend to kill people. Therefore I'm not allowed to use Reticulum to coordinate with my mates, even though most people would agree that I'm not killing immorally.
> even though most people would agree that I'm not killing immorally.
They’d only agree in the abstract. As soon as you name the oppressive regime you’re fighting against, suddenly a huge chunk of those people will come up with reasons to no longer support you.
That's still a restriction on freedom. Some people's notion of malicious might disagree with the author's.
I suspect such groups don’t really care about abiding by the terms of a license agreement. You can sue them… if you can find them.
The maintainer is actively saying they’re stepping back from the project
so explain to me how the license is going to be enforced?
And just because e.g. AI companies violate copyright to train their models and get away with it, doesn't make it right. The same principle applies here.
The exact text is "The Software shall not be used in any kind of system which includes amongst its functions the ability to purposefully do harm to human beings."
This is an example of the HN "Jump to Conclusions Mat" where there is an instant jump to extremely high level politics and philosophy and skipping over the more practical mundane problems.
A more practical issue is the author has zero interest in being sued if my LoRA connected emergency stop button for my CNC milling machine crashes and the machine then hurts someone (possibly myself).
Or my "emergency alert" transponder fails when I'm in the wilderness and someone (maybe me) dies instead of being rescued.
The wildest part of the story which isn't being covered is this is an example of one guy doing all the work to produce something more capable than the entire meshtastic project in about a year. A real life example of 10x or 100x engineers. How can meshtastic accomplish so little if one guy accomplished so much? Historically it was not THAT bad where having more than one person work on a network protocol never killed progress for decnet or banyan vines or SNA or any other old time protocol, but maybe its a mesh network thing that having more than one cook in the kitchen eliminates all progress.
Unfortunately, being a pretty much 1 person project he doesn't have the legal skills to realize the license as written is awful and needs rewriting to achieve his goals, assuming his goals are even a good idea...
I've set this up and used it on my LAN at home. Its a LOT more than just LoRA or just meshtastic and its pretty cool and works well. The app on my phone works well. Being abandonware I'm shutting it down "when I get around to it". The ratio of Meshcore to Meshtastic users/traffic is around 20:1 in my area so I'll be setting up Meshcore to fit in. Mesh LoRA is very local just like cell phone service; I'm well aware there are parts of the world operating at an opposite ratio of popularity where you "have to" use meshtastic to fit in. That is not where I live so I must use meshcore.
Meshtastic isn't used here, so I can't mesh so cross that off. Reticulum works perfectly and is abandonware so cross that off. Meshcore has its ... interesting pay money to unlock features scheme, I can't decide if I like or dislike that, I'd like to cross that off but its the only remaining protocol. I could write my own and GPLv2 it but if a superior system (reticulum) can't get buy in, my better licensed system would also be unused. I think I am stuck having to use Meshcore, I about 95% like that and 5% dislike that.
I do find it amusing that I used ham radio AX.25 packet radio in the late 80s, early 90s, some times this century, I know all about digipeating problems and hidden transmitter problems and all the stuff the "kids" refuse to do a literature search for and seem surprised when it bites them. Really this mesh stuff is just ham packet radio from 1981 except the total cost of a station is like $15 vs back in the day it was oh at least $1000. I had a node running linux AX25 back in the 90s and I'm sure I had a couple thousand bucks in equipment by the time I was done, mostly repurposed later on. I still have several hardware TNCs in some closet or shelf somewhere...
> A more practical issue is the author has zero interest in being sued if my LoRA connected emergency stop button for my CNC milling machine crashes and the machine then hurts someone (possibly myself).
Don't most actual free software licenses include a warranty disclaimer? So said military would have no grounds to sue, since there's no warranty or guarantee of function provided.
Thing is, I want to like Reticulum. It's a great protocol, way better than Meshtastic. It has a great vision. IMO it's not abandonware (yet) but even if it was, I'd probably be willing to maintain it for myself. I just wish it was FOSS.
> The mental maps we carry are dominated by a single, misleading image: The Cloud.
> To break free of the center, you must also let go of the concept of the "Address".
When I was still dealing primarily with on-prem networks in regulated environments (or cloud networks stubbornly architected in a fashion similar to on-prem ones) I worked with a lot of people that could not and would not ever understand this. It's not just a cloud thing. Some people just cling to using IP addresses for everything all the time. They don't understand why trying to access the JIRA server via IP wouldn't work because they didn't understand SNI let alone a Host Header. Dynamic record registration and default suffix settings are nothing more than a section of settings to be cruised over during clicked-in configuration. Zones can and should be split without regard for architecture or usage. Et cetera.
My theory is that because these people didn't understand Layer 7 stuff like HTTP or DNS they just fall back to what they can look at in a console (Cisco ASA, AWS, or otherwise). IPv6 will simplify a lot of the NAT stuff but it won't cure these people of using network addresses as a crutch. Not really sure what the systemic solution is - I was like this once but was fortunate enough to be task with migrating a set of BIND servers to the cloud and so learned DNS by the seat of my pants. Maybe certification exams should emphasize this aspect of networking more.
I love that Mark Qvist publishes his strong opinion, view of the world, and goals.
It quite smells like the hacker spirit of the 80s, mixed with a little spiritualism and anarchism. Very refreshing after so many other people are just disillusioned, worn out, angry, or frightened.
Good to see recent writings and changes, I had taken from the December 2025 blog post that the maintainer was done: https://unsigned.io/articles/2025_12_28_Carrier_Switch.html
Not much "Zen" when it barely works under i386 (Atom n270 CPU), 1GB of RAM and a simple 80x25 terminal. Sadly, even my usual one (100x32/36) isn't good enough to please retrowannabe hipsters.
i see this project more of a high security deployment. a sort of red phone network. in a post apocalypse scenario, we can do open networks on lora, plus at that time, we gonna need text manuals for agro, fabrication etc... essentially survival wikis.
A nice citation in MIRROR.md - असतो मा सद्गमय तमसो मा ज्योतिर्गमय मृत्योर्मा अमृतं गमय
Also discussed here: https://news.ycombinator.com/item?id=46686273
Mentioning HAM-based internet is cool too eg. HamWAN
Oh I guess that falls under packet radio I see
At some point we will be so tired of distinguishing between AI generated content and human content that we will stop using the Internet and it will be left to bots.
Dead internet theory [1]
1: https://en.wikipedia.org/wiki/Dead_Internet_theory
Personally I'm waiting for the "everyone is 12 internet theory" to get a Wikipedia page. (Of course I am - I'm 12)
non-wikipedia garbage site reference: https://sg.news.yahoo.com/viral-everyone-12-now-theory-19314...
Middle out