This is an answer from Mark Qvist reg. my question about comparison btw Reticulum RNS and Meshtastic:
All in all, it’s two very different things.
In general, Meshtastic is a single, monolithic application, very insecure, and not very flexible. Reticulum is a full networking stack - a system to build any kind of application on.
One thing already built on Reticulum is the open LXMF protocol, a very flexible messaging system, which in turn has a number of different clients already, that can run on both mobile, desktop and headless servers:
GitHub - markqvist/LXMF: A universal, distributed and secure messaging protocol for Reticulum
GitHub - markqvist/Sideband: LXMF client for Android, Linux and macOS allowing you to communicate with people or LXMF-compatible systems over Reticulum networks using LoRa, Packet Radio, WiFi, I2P, or anything else Reticulum supports.
GitHub - liamcottle/reticulum-webchat: A simple mesh network communications app powered by the Reticulum Network Stack.
GitHub - markqvist/NomadNet: Communicate FreelySince all clients use LXMF, they are interoperable, and anyone can easily write new clients using the available libraries and packages. It’s also super easy to write bots, scripts and automations.
As you can imagine, most LXMF clients can already do everything that meshtastic can, and often also a lot more. The new “Reticulum Webchat” client by Liam Cottle already has experimental voice calls, and it works over LoRa too (because of Reticulum). And Sideband, for example, also has:
- No limits on amounts of users, or only 80 addresses per “channel”
- Offline, delay-tolerant and failure-resilient distributed message storage
- File transfers
- Sending and receiving images
- Infrastructureless location updates and telemetry
- Remote commands and requests
- A fully fledged plugin system
- Can run on both Android, Linux, macOS and Windows
- Headless server mode
- Can use any medium to communicate, not just LoRa
- Has unlimited network size
- Has unlimited amount of endpoints and messaging adresses
- Has global reachability
- Has complete and universal self-ownership of addresses
- Addresses are completely portable to any network
- Reticulum handles global mesh routing automatically
- Does not depend on any internet-based servers to function
LXMF is just one protocol built with Reticulum. The sky is the limit, and once you have a Reticulum network, any Reticulum software works over it, of course. Reticulum already has many other programs that are fully functional and works super well, even over very slow LoRa, such as:
Fully interactive remote shell (like SSH), with the “rnsh” program:
GitHub - acehoss/rnsh: rnsh is a command-line utility written in Python that facilitates shell sessions over Reticulum networks and aims to provide a similar experience to SSH.Low-bandwidth pages, and interactive page-like applications with NomadNet:
GitHub - markqvist/NomadNet: Communicate FreelyBrowse Wikipedia, or any Wiki/ZIM over nomadnet:
GitHub - RFnexus/Retipedia: RetipediaHere’s a user browsing Wikipedia over a 120 kilometer (super slow) HF NVIS link:
https://youtu.be/blwNVumLujcRemote file transfers over anything with the “rncp” program:
Using Reticulum on Your System - Reticulum Network Stack 0.7.5 beta documentationMany more included utilities in RNS core:
Using Reticulum on Your System - Reticulum Network Stack 0.7.5 beta documentationWeb-flasher tool to flash RNodes from a browser:
https://rnode-flasher.erethon.com/The above is just a few examples, there’s a lot more to dig into in terms of what people are currently building with Reticulum.
Check some of the nodes on nomadnet as well, there’s forums and messageboards, all kinds of weird and wonderful pages, including an air alert map for Ukraine, a collaborative paint application, a complete collection of bibles, poetry sites, libraries of strange books and probably all kinds of stuff I don’t even know about.
Here’s a few old posts from the github forum with some discussion and comparison about meshtastic. Please note that this “trosel” user primarily using the forum and matrix channel to create covert advertisements for meshtastic, but so far we just let them roll with it, since it does spark some good enough discussion and clarification on the topic.
Video about Meshtastic LoRa messaging device · markqvist/Reticulum · Discussion #487 · GitHub
Meshtastic · markqvist/Reticulum · Discussion #77 · GitHubTo finish off, I’m going to just paste in some text and answers from various chats in matrix channel discussions. It’s going to be a bit out of context, but you can hopefully get something useful out of it anyway!
The security and privacy of Meshtastic is practically non-existent.
There’s only one single, shared, static and symmetric AES256 key per MT “channel”. This key is stored on every radio device, and to be part of the “channel”, you need to have it. If this key is leaked at any point in time, or someone loses their device, and an adversary picks it up, or any other of the myriad ways the key could get leaked, ALL communication - past, present and future - from any of these devices can be decrypted by an adversary. It’s very easy to mass monitor and record LoRa spectrum.
(this was an answer to someone on twitter asking me why I did not consider meshtastic to be secure or sufficient even for casual use)
Thanks, I’d love to! The short version is this:
If I demand that everyone encrypts messages with the same AES256 key, and then write the encryption key with a sharpie in your forehead, you have something pretty close to Meshtastic.
Here’s the longer version:
Don’t get fooled by crypto number games. Meshtastic users often brag about “military grade AES256 encryption” and similar nonsense.
Why would I know any better though? I actually read the entire source code for their implementation, so I know exactly what is going on under the hood. I have worked in critical infrastructure security for a long time, and have implemented a number of crypto systems that are in use in the real world.
So, this is what Mestastic calls “encryption”:
We’re gonna encrypt all messages with a user-defined, symmetric AES-256 key, and then you must hand around the key to anyone you want to communicate with. In fact, you will have to make sure that everyone that wants to communicate with you as well, will all use the same key, and also for communicating with each other.Also, there is no rotation of keys, ever.
Also, those keys are stored completely unencrypted and unsecured in the flash memory of the Meshtastic radio devices.
All you need is a phone, a USB cable and 3 seconds of time to extract the channel key from a device you happen to be able to get near, and you can now decrypt ALL traffic previously recorded for that channel.
Is that proper encryption? Absolutely not. It is basically useless. When that key inevitably gets leaked (which we, in any serious security assessment) would consider it to be from the very beginning), ALL communication - past, present and future - from any of these devices can be decrypted by an adversary. It’s very easy to mass monitor and record LoRa spectrum. It’s happening right now, by governments, corporations and private individuals.
This is SO BAD I cannot even understand they have the gall to advertise it as being “encrypted”. It’s the same kind of misleading nonsense that have gotten real people into real danger, time and time again. Yes, people will get arrested, beaten (and worse) because of this. Please, please, please, DO NOT PROMOTE MESHTASTIC AS SECURE. It simply is not.
If you were conspirationally minded, I’m sure you could easily come up with some kind of theory behind all of the hype about “the dangers of meshtastic and LoRa to national security”, etc., etc. I’m not interested in that though, I’m interested in providing actually secure, reliable and functional networking and communications solutions to humans.
Regarding scalability, meshtastic is not a real “mesh”. Devices are just dumb repeaters that mindlessly echo received messages according to semi-random probability. It works for small amounts of devices, but breaks down as soon as the network grows just a tiny bit, due to the very limited bandwidth available, and the exponential rise in traffic transport cost on such dumb “flood-fill” networks. There’s a reason that methodology was abandoned in the 80s.
In Meshtastic, there is no real routing, no globally unique addressing, and no way to reliably interconnect isolated network segments. Since there is no routing, you cannot use it as any sort of just semi-universal communications tool. You have to physically meet people first, exchange keys, and even then you will not be able to communicate, unless you are relatively close to each other - beacuse at longer distances the “mesh routing” breaks down completely.
All transport of messages between networks that are physically more separate than what their flood-fill “routing” can handle must happen over applications and protocols that are completely tied into the existing Internet ecosystem. If that fails, all Meshtastic communication will be limited to very isolated and small pockets, without any way to interconnect them again.
I could go on, but I guess this is enough to point out the most obvious flaws, and how they very much dissonate with their image and marketing.
I’ll let you be the judge, and feel free to ask me any questions, btw.
Cheers,
Mark
Regarding this statement:
If anything they (Reticulum) will have a harder time as bandwidth gets used up since they can’t tell who’s sending messages and thus won’t even be able to set up no-route rules on their repeaters.
No, that is not a true statement.
Usage regulation should not be determined based on service address banning an “no-route rules”. That’s not network performance regulation, it’s censorship. And on top of that, it doesn’t work.
Bandwidth is a physical resource of the natural world. Reticulum is based on the principle of creating systems that (as far as is possible for a computer program) understand the physical limits of real-world resources, and manages them responsibly and intelligently, with well-thought out algorithms. When that is ultimately not possible any more, human beings have to step in and expand capacity or make other thoughtful decisions on how to manage the available resources. I believe this is the most efficient, holistic and human-friendly approach to creating technologies that actually help us and better our lives.
Reticulum is about an order of magnitude more efficient than the “routing” (wasteful dumb repeating) that meshtastic uses. From the very outset, it seems quite strange to talk about bandwidth consumption issues there, when meshtastic has that problem build into the very core premise of the system. There’s a reason that methodology was abandoned in the 80’s. Meshtastic is worse than ALOHA-net in terms of coordination and bandwidth performance. It’s also worse than AX.25 + APRS, a technology from the early 90’s.
It’s very easy to manage and regulate bandwidth consumption in Reticulum networks, since it’s exceedingly simple to just add more APs once capacity limits are reached, and segment the users between more APs. No reconfiguration or setup required. Literally, just add the AP hardware, and Reticulum automatically handles everything. Things like this are fundamentally completely impossible in meshtastic due to their dumb-repeating methodology.
In this scenario, Reticulum definitely scales a lot better. There are no hard limits on number of users, addresses or endpoints in the network, making it much easier to share available spectrum.
Reticulum is also a lot more efficient with bandwidth, since meshtastic relies on every packet being repeated semi-randomly many times by a large number of nodes to (maybe) reach the final destination. Reticulum creates an efficient and properly encrypted link, that is routed over a single path in the network, making it often an order of magnitude more efficient. The path can be renewed and rerouted for every link, but packets going over it does not have to be repeated needlessly, so none of the precious bandwidth is wasted.
Since Reticulum allows the efficient use of mixed-medium networks, it’s also possible to create networks supporting many thousands of users easily, which meshtastic currently cannot support in any way. An example topography would be a network where a backbone of long-range 2.4GHz connections support a wide distribution of LoRa (RNode-based) access points, that users connect to.
You can scale such a topography almost infinitely, since the 2.4GHz backhaul/backbone connections have capacity to handle many hundreds of LoRa access points. I’ve personally built Reticulum networks like this using Ubiquiti Point-to-Multipoint 2.4GHz/5GHz radios and RNodes, and they work and scale incredibly well. Power consumption of such setups are also low enough to deploy on solar-powered off-grid sites.
In a scenario where you have a local RF-based network that interconnects a community spanning a large area, with radio access points providing access to users in the entire community, it would look something like this:
- When the grid/internet-connected nodes have connection to the wider internet, everyone on the entire community reticule would be able to communicate with each other, and anyone else in the world that are on interconnected reticules. Bob can message aunt Alice in Wisconsin, as well as his friend down the road. Inter-community traffic never leaves the community reticule, and is routed in the most efficient way directly to the destination.
- When the internet disappears, everyone within the community can still communicate with each other. If just one of the Reticulum transport nodes that are connected to the community reticule regains connectivity to wider networks (the internet, and thus internet-connected reticules), everyone on the community network can now communicate with everyone else again.
- Reticulum and LXMF also handles intermittent re-connections to a wider net. If LXMF propagation nodes exist on the reticule, messages destined for users beyond what is currently reachable will get picked up by the LXMF propagation nodes, and these will attempt to “get them out” to wider networks when a window of oppertunity appears, as well as “bring in” messages from wider networks that may be waiting for users within.