The Zen of Reticulum

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

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

> 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

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

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.

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

Mentioning HAM-based internet is cool too eg. HamWAN

Oh I guess that falls under packet radio I see

Also discussed here: https://news.ycombinator.com/item?id=46686273

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.

Middle out

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.