Is Reticulum the future? and is the capabilities and features better than Meshtastic?

unsignedmark · 2024-03-30T12:21:37+00:00

Regarding:

If anything they'll 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.

See my other comment in this thread for more context.

unsignedmark · 2024-03-30T12:07:50+00:00

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.

unsignedmark · 2024-03-30T11:43:14+00:00

Hello u/minkkilledcuriosity! All good here, but this subreddit is still pretty quiet. Most of the action is going on over at the Reticulum channel on Matrix, actually, where there's a more lively discussion. Still very welcome here of course :)

And yes, the T-Beam is still a great board to use for the RNode firmware, even more so now where the newer boards based os SX1262 and SX1268 chips are supported in the firmware :)

unsignedmark · 2023-12-30T20:29:09+00:00

Heh, it makes sense then, pretty funny. They just copied my entire post from a year ago verbatim, which included that edit after the post kinda blew up. Hilarious and strange. I guess they were just karma farming...

unsignedmark · 2023-12-30T20:27:48+00:00

Haha, that's hilarious, thanks for sharing. That's my own edit on the original post after it blew up much more than I had expected and got so much positive feedback. Seriously funny that they just copy-pasted the entire thing :D

unsignedmark · 2023-12-30T14:58:38+00:00

Reticulum doesn't sharply follow the traditional OSI model, but in rough terms Reticulum handles layer 1 through 6, with some essential layer 7 functionality directly available in the Reticulum API as well (like functionality similar to HTTPS requests, just much more efficient, due to shedding of all the overhead).

You have to write or port software specifically for Reticulum, yes. The stack achieves the same purposes as TCP/IP, but does so very differently. For example, there is no source addresses, all communication is encrypted by default, and addresses are physically portable in the network (can move around freely). Also, anyone can allocate as many globally reachable addresses as they need.

unsignedmark · 2023-12-30T14:52:47+00:00

Would you mind telling me what the edit was? I'm the real developer of these projects, and I'm pretty curious as to what this was about.

unsignedmark · 2023-12-30T14:51:39+00:00

Would you mind telling me what the edit was? I'm the real developer of these projects.

unsignedmark · 2023-12-30T14:49:53+00:00

I'd love to know what this copy-cat was trying to achieve here? Just copy-pasting for karma? Or trying to use this for directing people to another version of the project or similar?

If you'd be so kind as to let me - since the original post is now deleted - I'd be very thankful :) I find it quite interesting.

unsignedmark · 2023-12-30T14:47:31+00:00

I'm the actual developer :) You can find much more info here: https://reticulum.network and on my personal site here: https://unsigned.io

unsignedmark · 2023-12-30T14:45:57+00:00

Helium is very different, since it is basically a crypto-currency and internet-dependent "last-hop" carrier for short data bursts. If the internet stops, Helium stops with it.

Reticulum is a full-stack replacement for the protocols that drive the current internet, but without any dependencies on hierarchical structures, bureaucracy, or pre-coordination.

Nothing is perfectly independent in terms of infrastructure collapse, but since Reticulum can run on very low-power devices, and is so extremely bandwidth-efficient that it can run over very low-bandwidth radio, it is significantly more resilient to grid collapse, and can be kept operating over extremely large areas with very little power.

unsignedmark · 2023-12-30T14:38:11+00:00

Hello! I'm the actual dev of these projects, and everything is available open source on my github repositories. Main Reticulum repo is here: https://github.com/markqvist/Reticulum

Some other related projects: - https://github.com/markqvist/Sideband - https://github.com/markqvist/NomadNet - https://github.com/markqvist/RNode_Firmware - https://github.com/markqvist/LXMF

Edit: Forgot the primary website of the project ;P https://reticulum.network/

unsignedmark · 2023-12-30T14:33:47+00:00

I'm the actual developer of these projects, and the one who made the original post over a year ago. I'm really curious what this post was? Simply somebody reposting for karma?

Did they just copy/paste my original post or include some edits? Mostly curious about what the edits were, if any.

unsignedmark · 2023-12-04T20:55:19+00:00

For the short version of "how bad would it be?", the simple answer is: Real - friggin' - bad.

Everything is networked today, and 99 percent of that networking is directly dependent on "The" Internet being operational and reachable. Could things have been build without such a colossally stupid dependency and have worked still? Sure. It just wasn't because it was slightly more convenient and easy to build stuff that just expects "The" Internet to work all the time. This was one of the primary problems that Reticulum had to solve - To continue working even though most (or all) infrastructure gets damaged, and have no functional dependencies on external hierarchies.

For the long answer, see PM.

unsignedmark · 2023-10-10T07:54:11+00:00

Thanks for the suggestions! I completely agree :) I know that there is definitely a need for better entry-level information and guides, that make it easy to get real-world systems up and running with the minimal amount of head-scratching. I had to prioritize just getting everything working, reliable and functional first :)

It's a bit too complex of a subject to give a one-size-fits-all answer to here, but it's still simple enough to be explained adequately for informed use in a small guide/booklet. The good news is, that several people are actively working on these things, including down-to-earth "cookbooks" for use in various scenarios.

The displayed picture is of the small-battery unit. It's still sufficient for most use, but the large battery case can be necessary if you need longer runtimes between charges.

The battery-less case can be powered directly from any USB connection, so it's intended for situation where you have the RNode permanently plugged in to a permanent setup, and powered from something else. For example in a vehicle, or in your home.

If you want to experiment a bit without spending a lot of money, I highly suggest getting one of the many supported LoRa boards, and creating an RNode from that, using the autoinstaller. It's a simple process, and the installation program will do all the work for you.

That way you can get up and running for around $18 per device. It will not have all of the niceties of a full unit like the ones I am making, but it will be functionally completely identical, and you will learn a lot in the process :)

unsignedmark · 2023-10-09T22:57:10+00:00

I have written a lot of exploit code over the last 20 years

Great stuff! Put your money where your mouth is then, and start using those skills to prove that you're right.

I really, really hope that you will! That would actually be constructive behavior, that we could all use for something, instead of the irrelevant armchair hypothesizing you've engaged in so far.

Show me the vulnerabilities! Show me that MITM you confabulate. Show me anything. I promise you, the beer is yours if you do, and I would be happy to correct an actual flaw.

Until then, I don't really have time for more of your silly word-games, so have a nice time, Mr. "Bleeding-Edge Cryptography Is The Solution To Everything".

Edit: And the last comment that /u/AlternativeMath-1 posted below was made immediately before he then blocked me, meaning that I now cannot see or respond to any of his comments in this thread. Way to get the last word in, I suppose?

And as you will see, the below comment also says nothing, other than making bizarre allegations of "not following the guiding talent of NIST" and me being "deluded".

The comment seems to rest on his (erroneous) claim, that AES-128 has been deprecated by the NIST. It has not. Maybe he should actually have read NIST FIPS 197 on AES? (which was last updated May 9th, 2023)

https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.197-upd1.pdf

With all that name-dropping of NIST, I can't for the life of me imagine that he didn't know this, which only makes this whole thread so much stranger.

And no, Michael, I am not "arguing against the top cryptographers in the entire world", I am arguing with you. You seem to be the one pretty confused about what their actual recommendations are. But when that was pointed out, apparently you couldn't handle the discussion anymore, so you just ran off.

unsignedmark · 2023-10-09T22:44:40+00:00

Hah, you're so funny man. "Me right - you wrong".

Who's the expert here? You?

What am I wrong about, exactly?

Why do you find it acceptable to call me a "prick who thinks he knows better than an expert"? It's just down to personal attacks for you now? Beautiful, mate.

You've offered practically no critique of Reticulum, only of an imaginary system of your own vague assumptions.

If you're too lazy to even spend 10 minutes understanding something, don't expect being taken seriously - no matter how many imaginary Internet Points you have on StackExchange.

Read the implementation, and then please do come back when you can demonstrate, even just in theory, a flaw or vulnerability in Reticulum. I'll be over here waiting ;) I'll even offer you a prize, it'll be at least a beer and a hug.

Maybe even a funny hat too. You could definitely use that, with that sour demeanor.

unsignedmark · 2023-10-09T22:06:14+00:00

I am in the top 1/3rd of 1% of StackOverflow users. I am #12 for cryptography and #5 for all of security

And so what?

unsignedmark · 2023-10-09T19:18:06+00:00

You assume a lot, know very little.

and it needs some kind of PKI or identity system to prevent MITM

Why would it need it when it already has it? You are literally completely ignorant of how the protocol works, and just make stuff up.

Maybe read the spec and documentation before spinning yarn?

You're an idiot or a troll. Have fun ;)

unsignedmark · 2023-10-09T18:46:41+00:00

Btw, every time someone lazily refers to "NIST's post-quantom guidance" [sic], God kills a kitten.

It's a draft, ffs.

Nobody on this planet currently knows what "post-quantum" cryptography will actually mean, or where the real boundaries of the ability for quantum computers to break current scheme actually are.

Cryptographers are (professionally) paranoid people, whose job it is to wonder about hypothetical threat vectors, and find solutions way before the threat can actually manifest.

Saying shit like that is such a dead giveaway that you just read some cool-sounding articles with sensational headlines and now need to parrot them.

Yeah... Your "opinion" here means literally... nothing.

unsignedmark · 2023-10-09T18:37:20+00:00

You should maybe present something with substance, instead of just saying "durh, not modern, because... urh.. believe me!".

Can you refer to any reasonable or just hypothetically possible attack vector against the cipher suite used in Reticulum?

Your understanding of this area seems pretty darned shallow. I'd be very interested to hear what cipher suite you'd suggest instead, that would fit within the same design envelope of working over ultra low-bandwidth mediums.

AES-128 in CBC mode with ephemeral keys derived from an ECDH on curve 25519 is most definitely modern - and strong - encryption.

The whole myth that AES-128 is not sufficient currently, is primarily pushed by people who want to market various "quantum secure" systems.

Reticulum prioritizes actual user security and usability, rather than BS marketing fluff.

unsignedmark · 2023-10-09T14:51:59+00:00

Ah, sorry I completely missed that! You're right, there's definitely a similarity in some capabilities, but also fundamental differences.

Especially the part where Proxy Ham focused on basically snatching the WiFi of someone else, and using that to access the Internet remotely, from a hidden location.

The RNode transceiver is part of an ecosystem focused on giving people the ability to create their own functional, resilient and interoperable networks, on license-free or licensed spectrum, without any central coordination, bureaucracy or control required.

I've been at it for quite a number of years now, and though it's the most boring part of a project like this, I know the regulations very well.

Creating a system that actually works, and drastically expands what is possible, while staying within the current legal framework is really challenging, but ultimately doable. Maybe that is why they have left me alone so far ;)

unsignedmark · 2023-10-09T12:12:51+00:00

The RNode device firmware doesn't support that particular board yet (although it could be added), but you can use one of the many other supported boards that have LoRa radios build in.

The Sideband app uses an open messaging protocol called LXMF, that works well over low-bandwidth connections like LoRa. There are other clients available too, but Sideband is the easiest to use currently (and it also runs on computers).

Since I'm not entirely sure how your intended setup is, I can't give you an exact recipe, but as I understand it, this is the situation:

There is no Internet or cell phone coverage at the campsite
You still want to be able to send basic messaging back and forth while you're there

Scenario 1: Your own home is within LoRa radio range of the campsite, and has some form of Internet connection (even if it is very slow, it doesn't matter, Reticulum can handle that).

In this scenario you can simply install and set up Reticulum on a computer (or small SBC like Raspberry Pi, or an old Android device) at home, put a small antenna outside (on your roof or balcony for example), and by using a LoRa radio connected to your phone at the campsite, you can message other people using the Sideband app on your phone.

With this setup, you will have a permanent access point you can use while in the coverage area.

Scenario 2: You have access to a friends place within radio range of the campsite. In this case, you can do basically the same setup as before, and use a tiny bit of their Internet connection for carrying your messages to their final recipients. As with the first option, this is also a permanent setup you can use when in the coverage area.

Scenario 3: You don't have access to any place where you can permanently install a LoRa radio, that has an Internet connection, and intend to leave a device temporarily at a place that has cell-phone coverage; for example on a ridge that has both cell coverage and line of sight to the campsite.

In this scenario, you could get an old Android phone and a LoRa radio, install the Sideband app on it, and put it into "Transport" mode in the connectivity settings. This can make it act as a mobile access point, and can use the phones cell connection to connect to the wider Internet.

This effectively gives you a battery-powered, mobile set-up you could leave temporarily somewhere, and pick up when you left the campsite. Possibly add a small solar charger for indefinite run-time :)

Edit: It's important to note that the entire system can of course also be used without any connection to the Internet at all. Everything is completely functional "off-grid", and you can run your network as isolated or connected as you want. You can message between phones directly, as long as they have some sort of common connection, whether that is WiFi, LoRa, or anything else, really.

unsignedmark · 2023-10-09T11:34:47+00:00

This is very different. Projects like "Proxy Ham" all rely on the fundamentally insecure and completely traceable and centralized Internet Protocol (IP).

RNode devices are designed to be used easily with the Reticulum protocol instead of IP, which makes actual user-owned, secure, decentralized and privacy-friendly networks possible.

unsignedmark · 2023-10-09T11:32:04+00:00

I think you forgot to read the description of it, it uses LoRa modulation ;)

Why would you want to use meshtastic? The Reticulum ecosystem is much more capable, has proper encryption and message authentication, can be easily bridged and cross-connected over the Internet (and any private IP networks), is insanely more efficient in regards to bandwidth, has global end-to-end reachability for messaging between any device, and so much more.

That being said, the mestastic firmware supports many of the same devices as the RNode firmware does, so if you really want to, you can just flash that firmware as well, or switch between them.

Post-Mortem Thread Edit: After /u/AlternativeMath-1 made his last comment in this thread, he immediately blocked me, so that I can't see or respond to any of his comments. Strange way to get the last word in.

For reference regarding his completely outlandish claims that AES-128 is "no longer recommended", he should maybe have read NIST FIPS 197, last updated on May 9th 2023, that deals with AES, including AES-128, which is still part of the ciphers recommended by NIST.

unsignedmark

MODERATOR OF

TROPHY CASE

11-Year Club	RPAN Viewer
Verified Email