Hacker Newsnew | past | comments | ask | show | jobs | submit | Panda_'s commentslogin

RNS doesn't really map to the OSI model very well. It takes up basically every layer, 2-6, although it does depend on how it's used. The image on https://linuxinabit.codeberg.page/blog/reticulum/ quite near the top explains the difference between Reticulum and, as an example, TCP fairly well.

Your point about not having encryption is really quite interesting to me. I would want to add some form of signing to prove something came from somewhere unaltered, but that would go against the idea.


Sounds a lot like something that could be used with https://reticulum.network to create networks that support multiple mediums.


I did not yet watch the full video, but Data Slayer on Youtube made a video about this, I guess. It's at https://www.youtube.com/watch?v=5vbl5FL-nsI


Reticulum creates networks but over radio the bandwidth is so limited that what you can realistically send are just messages.

There are more efficient protocols like APRS and more recently XPRS.


Overall this post seems a bit like you've got a grudge against the project. Is it related to the fact you made a post about your vibe coded SPORE project which looks inspired by Reticulum?


Not including a link is quite odd...


Link? Why won't you just take his word for it? What is this world coming to?


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


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


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


Having Nomadnet in Go would be a great thing to have (and no more Rust dependency because of Python-Cryptography).


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


There's a thread by the author of Reticulum [1] on recent flooding attempts of weird clients connecting, spamming path requests and leaving, and attempting to mitigate their impact on the nodes.

Yeah it seems like you are in fact right...

[1] https://rns.recipes/forum/general/rns-150-testing-traffic-pr...


So it has already begun. It's kind of sad/impressive how every single network or group project gets flooded with abuse as soon as it gains any tiny bit of attention.


Mark accepts outside contributions over LXMF using git patches. The main communication method is over Reticulum Relay Chat using clients like NomadNet (made by Mark, unintuitive but works well) which is basically IRC and is purely sending messages to everyone in that channel at that time and is centralised around self hosted servers.


Reticulum packets include a hop count of how many nodes it’s been through (to prevent packets looping indefinitely) and the destination address. Two way links use tables on each node to reverse the route back to the origin and don’t use origin addresses.

The worst part privacy wise could be the announce packets which include a hop count and the address for the origin so if you had enough interfaces you could roughly say where a node is on a network graph (geo locating that is an entire other problem)

Privacy also depends on what interfaces you communicate over, eg TCP reveals IP addresses to the nodes you directly connect to (combine with hop counts to see if a packet definitely originated from that node), LoRa gives an idea of how close it might be because of its range limits and the fact radio emissions can be located.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: