Live data from Hacker News

Reticulum – Decentralized Mesh Network

reticulum.network

71–80 of 89 posts

Re: Reticulum – Decentralized Mesh Network

#71
post #18

Earlier quoted context omitted.

People don't seem to get this was a genuine question. What is a network without people using it? Anyone here on reticulum? The internet may be ripe for disruption, as it has been domesticated for corporate use. It is no longer ours. Browsers have become an operating system unto themselves. Something much simpler would work also. Corporate bloat is continuing to pile up, while markdown evolves to do everything we want…

> Anyone here on reticulum? Is that even the right question? I only read the intro message but the framing I arrived/guessed at was: "open, distributed alternative to tailscale" So I think my first usecase would be to use this instead of tailscale to connect to my Pi?

Tailscale is a different usecase entirely, as this comment demonstrates: https://news.ycombinator.com/item?id=49328580

Re: Reticulum – Decentralized Mesh Network

#72
I have a lot of hopes for Reticulum, but my experience has been that it is not widely deployed and really requires network-connected LoRa nodes to be worthwhile. As a pure LoRa protocol, I think MeshCore and Meshtastic are more useful, and while Meshcore has a better design of the two, Meshtastic by far has more adoption/critical mass.

Re: Reticulum – Decentralized Mesh Network

#73
post #59
post #19

https://ratspeak.org/ seems like a modern fork of Reticulum built in Rust and with a fairly active community

That should be rewritten in Go instead of the dead-slow Python release under 32 bit machines.

There's an RNS implementation in Go at https://github.com/Quad4-Software/Reticulum-Go but

Re: Reticulum – Decentralized Mesh Network

#74

What is confusing to me is that this is intended to be run (I believe) on LoRa devices, but it requires a PC with python running. I researched this for a project at work involving these devices. (Sx128x or sx1262 LorA radios connected to an ARM MCU). I skipped it and used the radios directly due to the Python requirement; these devices, which seem like they would be the Reticulum target, run bare-metal or RTOS, i.e.…

There's a LoRa firmware at https://github.com/attermann/microReticulum_Firmware which looks to be fairly well supported

Re: Reticulum – Decentralized Mesh Network

#75

I wanted to like Reticulum. I found it was unstable and often crashed my tower—particularly Nomadnet. I feel like if something similar was made in C, it probably would be pretty okay, although I have noticed the kinds of people I interacted with there were kinda jerkish on average. Of course, the internet in general has that problem, so that's not a "new thing", but I guess the "I'm totally off the grid, bro" has its…

Try disabling the default AutoInterface in the config, that can cause problems due to some routers choking on UDP. If it still crashes anything, that's almost certainly a bug you can report

Re: Reticulum – Decentralized Mesh Network

#76
I have also put some thought to this problem and after reading some here are my definitive conclusions that still remain for all mesh networks to achieve:

- We need hardware that solves radio mesh problems:

  - Multifrequency (more than 8 bands and frequencies with different range) with programmable hopping between them (as opposed to LoRa default hopping which is random). I will use LoRa hardware for now on 169MHz to increase range and force frequency change in a non-random way. Still as mentioned LoRa rules cannot scale so we will have to build it in a non scalable manner and then change the limitations if adoptions ensues.

  - The radios need to be able to receive on many frequencies at the same time, atleast for the stem nodes.
- We need glue between old sync. IP/TCP/UDP (HTTP/SMTP/DNS) and async. IP2/"events" as he calls them.

- To scale geographical position is paramount and to remain independent of GPS we can use trilateration.

- The debate about encryption is a problem because it will have to evolve and to hardcode it into the base protocol will cause big disruptions down the road. I suggest the base layer is open and you apply encryption at the end; the reason for this is that privacy deters scalability and I prefer to have a truly scalable system that knows your position than the other way around. (also less chance the network can be used for military purposes then)

The resolution of range negotiation also has to be very granular: One freq. has to be the main "I'm here" channel and then dependent on density you have to releagate nodes to smaller and smaller range frequencies because a large city needs to cover a density of many thousand nodes per square kilometer.

So 169MHz is a good starting point (for range and less hops to reach bridge nodes) but you eventually need 433 and 868 too in the same device the main problem then becomes the antennas!!

To aim for complete decentralization over only radio is probably too optimistic, we could aim for distributed centralized independent networks instead with fiber interop so that mail and very simple web works on the base implementation to give immediate usability.

Finally a note on privacy, Tox is the only usable network that tried this and ohboy is it difficult to get any normal human being to adopt it when they have WhatsApp that has all humans on it allready.

To me unencrypted SMTP is a better attack vector because it is even more widespread and can be encrypted very easily later. Except of course destination encryption which works against scalability as I said previously.

The final reason I'm putting more energy into MMOs is that radio is easily disrupted and so far our existing internet show little technical reasons to abandon it yet. That can change in a heartbeat though.

Edit: Receiving my first meshtastic hardware for the C64 in a week or so but I still believe nobody has solved the scalability yet. I will eventually try to over at http://radiomesh.org

Re: Reticulum – Decentralized Mesh Network

#78

A Reticulum destination is a hash of a public key, so the address and the identity are the same object. That makes rotation awkward. There is no obvious path from a compromised key to the same reachable name. Lose the identity file and the address is gone.

No, a destination can be named.

Why use AI to write Hacker News comments... to what end?

Re: Reticulum – Decentralized Mesh Network

#79
post #37

While the project is interesting from a technical perspective, there are some serious issues. The main implementation has a vague, non-standard licence, but this is not overly problematic as alternative implementations can simply be used instead. A bigger problem with Reticulum is that it does not appear to offer robust protection against abuse. Messages are protected by cryptography, but there are many other ways to…

Any publicly accessible protocol, such as Ethernet (wired and wireless) can only do so much to prevent DoS/DDoS on a given open multiple access medium. You can certainly bake in fairness, congestion control, etc. in the protocol level, but protocols require 2 participants to follow rules/spec to work, and if one side doesn't follow the rules/spec, at the very least some bandwidth will be consumed. The only way to abs…

Of course, you can't protect against all types of abuse perfectly, and an attacker will always be able to degrade the network to some extent. However, I fear that a larger Reticulum network would become unusable if an attacker put in even a modicum of effort. You could whitelist everything, but then the project would lose its core goal of being a free network.

Re: Reticulum – Decentralized Mesh Network

#80
post #67
post #37

While the project is interesting from a technical perspective, there are some serious issues. The main implementation has a vague, non-standard licence, but this is not overly problematic as alternative implementations can simply be used instead. A bigger problem with Reticulum is that it does not appear to offer robust protection against abuse. Messages are protected by cryptography, but there are many other ways to…

> robust protection against abuse I would say it has a fairly reasonable number of protections with things like being able to prioritise certain interfaces and controlling the announce rate from a node and rate limiting the number of announces a destination makes. What in particular is abusable?

I can't see any effective protection against the classic tactic of flooding the network. There are some defences in place, but they seem easily overcome with minimal effort. If everything has to be whitelisted, the project would lose its core goal of being a free network.
Post reply on HN