Just to share some experience: 100% privacy on these kind of networks is more a sympton of talking to software engineers than the radio reality observed on mesh networks.
Very often what comes as top priority is communication itself, which means radio-amateur radio frequencies where encryption is only available for signing messages but not the content.
Reticulum can be 100% private as it can choose to send packets in plain text. Can also broadcast messages without a specific target receiver, these are features that are necessary for radio transmission on amateur frequencies.
On LoRa: attention that default reticulum is still "too talkative". Meaning that in some LoRa frequencies there is a legal limit to how many messages (transmission time) your device can send per hour and even the automated announcements (to say "Hello, I'm here") quickly waste that available space.
On Internet: reticulum is great. I'm seeing about 700 connected devices across different hubs.
People often compare reticulum to Meshcore or Meshtastic but they often neglect one important aspect: those are exclusive LoRa implementations. Reticulum is the same protocol (language) no matter the network underneath. This means that you can connect a phone via BLE to a LoRa link which on the other side is connected on the Internet and then flies down to another BLE somewhere. This is not common to find on reticulum but possible.
There is a lot of good work on the topic. Maybe it will surface here on HN soon when more stable. In October there is an yearly event in Coimbra, Portugal where these topics are presented and tested in deep.
Yeah, I got the impression that Reticulum's main claim is that it replaces the IP stack with a future-proof, encrypted protocol for routing regardless of the underlying network medium. Which is not an insigificant claim to test, but boy would it be fantastic.
Would say your understanding is correct. It uses something similar to a "gossip" protocol where the public keys of other users are advertised.
So it gets ride of IP addresses and can jump boundaries between different network types. I'm using it for BLE to BLE communication, I've seen videos of people using it for USB to USB communication. There aren't many limitations as long as data can flow.
Was trying to find it but hard. Reticulum only needs some kind of way for bytes to move from one point to another. So USB with the serial data line works as well.
On the video was using for an embedded device without WiFi nor Bluetooth to communicate with the host computer where it was connected.
I know what you are getting at, but I think that's an unfair characterization after all.
I don't want to shit-talk Ratspeak, but the foregone description of community and momentum seems far fetched. Additionally, the vibe is pretty off compared to Reticulum. Nothing here points to "successor" IMO.
I had a lot of hope for reticulum, but it's a one man project with a near burned out maintainer, taking on an absolutely monstrous task.
I'm now cautiously optimistic. This or something similar is likely the long term future of mesh networks, but in the short to medium term, meshcore is the way to go.
The protocol itself is more mature than the maintainer situation suggests. I built a complete independent implementation from the public spec in a few sessions. If one person can do that without touching the reference codebase, the foundation is solid. The risk is to Mark's implementation, not to Reticulum as a protocol.
That's good to hear. Having a proper protocol is the hardest and most important part. If everyone agrees on the protocol, different implementations can exist, forks can compete, and we get all the benefits of such without network fragmentation.
> Reticulum does not use source addresses. No packets transmitted include information about the address, place, machine or person they originated from.
Sure, but if it’s anything like MeshCore, a few observer nodes will be able to see which repeaters the message first entered the network from and from that know roughly where it was located.
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.
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. C, C++ or Rust with no or minimal OS, and no python.
There's a rust port of the Reticulum, but it's std rust, which has a similar problem to Python.
edit: The core problem isn't so much that it requires Python and a GPOS; it's that they don't publish a spec, and instead direct you to use their Python package; the code is the spec is another way of phrasing that.
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.
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 render a network unusable, which will inevitably happen on a larger scale.
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 absolutely prevent DoS/DDoS is to have more bandwidth than all possible simultaneous attackers, or limit physical access to the medium. Cellular networks, for example, keep direct physical access to its medium under tight lock and key through proprietary, non-open-source baseband firmware.
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.
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.
With the Artificial Inanity systems and the Rampant Orphan Botnet Ecologies (ROBE) beginning to spew tremendous amounts of crap (a technical term) onto the Ret, things are getting tricky for us ITA.
Rayfish, Tailscale, ZeroTier, Netbird etc are a different category of tool, designed to facilitate connectivity between you and your own pool of machines. They don't generally do much in the way of multi-hop routing, but rather they orchestrate VPN tunnels on top of another routed network (like the internet).
Reticulum would be better compared to Yggdrasil, cjdns etc as routing schemes for larger networks or true meshes, which can work independently of (and have no dependency upon) the internet.
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 new own hubris.
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
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
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.
The author of Reticulum's take is that the implementation is the specification, so if another implementation works with the standard Python one and implements enough of it's features then it implements Reticulum.
I suppose it means it's easier to develop the protocol only having to update one Python codebase but it does mean other implementations are kinda in a state where there isn't anything to properly verify they work.
There's also a issue with quite a few vibe coded implementations that don't actually properly work filling the space.
There is a published spec, I built a clean-room implementation from it. And mine makes at least two Python implementations. The protocol itself is solid, the spec just isn't marketed.
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.
People do use it but it's definitely a small community. It has the NomadNet Page protocol which is basically small no client side script webpages (forms and links only) in a fairly bandwidth efficient form.
[Gnomic comments go over people's heads (I'm guilty of writing these too). Gotta think in UX terms - write to make your audience's lives easier, not harder.]
You're right, and I think a lot of these projects hit the same problem: "what can this offer me that centralized platforms can't?"
Take the Gemini protocol: if someone invents a "Gemini killer app" it can be replicated over the web because the web's features are a superset of Gemini's features. Medium is the centralized equivalent of traditional blogging. Spotify is eating podcasting. The whole indie web could be emulated by Meta (it's not currently big enough for them to care). Much like capitalism eating subcultures, the existing LCD internet will consume, commoditize and re-sell all alternatives.
The only exceptions I can think of are decentralization itself (centralization can only offer an emulation of decentralization) and freedom from corporate censorship, and not enough people care about them to make the switch.
I'd love to hear counterexamples if anyone has them, because I don't like this conclusion.
I believe this project is primarily funded by functional autism and a sharp mind, enabled by a socially supportive environment.
It's mostly one dude who really went into the depths of it, considered a lot of details and managed to deliver a resolute implementation and presentation. Judging by the Ayn Rand quote, I believe he may ideologically fall onto the regarded side of the anarchist spectrum and may be less motivated by humanitarian aspects, as you may otherwise expect for "crisis resistant" technology. The rest of the small community seems to be made of similar libertarian type individuals, which may be one of the reasons why it doesn't gain more support). Regardless, in terms of economics, I believe the author actually decided not to play, so you may ask yourself, if you may have asked a leading question. I believe the actual answer concerning motivation is this: For the fun, the challenge and the beauty of it. It's a PoC/reference of an idea, rather than the answer to an immediate or anticipated need.
The ecosystem as a whole is a most lovely project to dive into, lot's of nuances to explore. Ideological differences aside, I am positively at awe, what the author accomplished there. Here is a spoiler, something stuck with me: A single RNode is enough to bootstrap the entire Reticulum network stack. It's web-hosting the firmware, software and documentation, everything you need, and every RNode can become a wifi access point for ad-hoc distribution. Beautiful, thoughtful feature you may merely accidentally stumble into, as it's just an understated side-note. The "it's just one guy" critique hits differently, when you see the extent of what that "one guy" actually accomplished.
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.
Just to share some experience: 100% privacy on these kind of networks is more a sympton of talking to software engineers than the radio reality observed on mesh networks.
Very often what comes as top priority is communication itself, which means radio-amateur radio frequencies where encryption is only available for signing messages but not the content.
Reticulum can be 100% private as it can choose to send packets in plain text. Can also broadcast messages without a specific target receiver, these are features that are necessary for radio transmission on amateur frequencies.
On LoRa: attention that default reticulum is still "too talkative". Meaning that in some LoRa frequencies there is a legal limit to how many messages (transmission time) your device can send per hour and even the automated announcements (to say "Hello, I'm here") quickly waste that available space.
On Internet: reticulum is great. I'm seeing about 700 connected devices across different hubs.
People often compare reticulum to Meshcore or Meshtastic but they often neglect one important aspect: those are exclusive LoRa implementations. Reticulum is the same protocol (language) no matter the network underneath. This means that you can connect a phone via BLE to a LoRa link which on the other side is connected on the Internet and then flies down to another BLE somewhere. This is not common to find on reticulum but possible.
There is a lot of good work on the topic. Maybe it will surface here on HN soon when more stable. In October there is an yearly event in Coimbra, Portugal where these topics are presented and tested in deep.
So what Matter is to Thread, Reticulum is to LoRa?
Nah, Reticulum is a agnostic to the underlying communication mediums. It can work over telegraph lines even
Yeah, I got the impression that Reticulum's main claim is that it replaces the IP stack with a future-proof, encrypted protocol for routing regardless of the underlying network medium. Which is not an insigificant claim to test, but boy would it be fantastic.
Would say your understanding is correct. It uses something similar to a "gossip" protocol where the public keys of other users are advertised.
So it gets ride of IP addresses and can jump boundaries between different network types. I'm using it for BLE to BLE communication, I've seen videos of people using it for USB to USB communication. There aren't many limitations as long as data can flow.
> I've seen videos of people using it for USB to USB communication.
How would that work? Do you have a link?
Was trying to find it but hard. Reticulum only needs some kind of way for bytes to move from one point to another. So USB with the serial data line works as well.
On the video was using for an embedded device without WiFi nor Bluetooth to communicate with the host computer where it was connected.
https://ratspeak.org/ seems like a modern fork of Reticulum built in Rust and with a fairly active community
Unfortunate name for the project.
Does it? It's seemingly one person on Github and the "community" is otherwise on Discord and Telegram, which is pretty sus.
I seems to have the first part in common with Reticulum.
I know what you are getting at, but I think that's an unfair characterization after all.
I don't want to shit-talk Ratspeak, but the foregone description of community and momentum seems far fetched. Additionally, the vibe is pretty off compared to Reticulum. Nothing here points to "successor" IMO.
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
do it
I had a lot of hope for reticulum, but it's a one man project with a near burned out maintainer, taking on an absolutely monstrous task.
I'm now cautiously optimistic. This or something similar is likely the long term future of mesh networks, but in the short to medium term, meshcore is the way to go.
The protocol itself is more mature than the maintainer situation suggests. I built a complete independent implementation from the public spec in a few sessions. If one person can do that without touching the reference codebase, the foundation is solid. The risk is to Mark's implementation, not to Reticulum as a protocol.
That's good to hear. Having a proper protocol is the hardest and most important part. If everyone agrees on the protocol, different implementations can exist, forks can compete, and we get all the benefits of such without network fragmentation.
> Reticulum does not use source addresses. No packets transmitted include information about the address, place, machine or person they originated from.
Sure, but if it’s anything like MeshCore, a few observer nodes will be able to see which repeaters the message first entered the network from and from that know roughly where it was located.
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.
reticulum don't just propagate over lora. IT can practically propagate over anything it supports (network, lora, bluetooth, etc).
it isn’t
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. C, C++ or Rust with no or minimal OS, and no python.
There's a rust port of the Reticulum, but it's std rust, which has a similar problem to Python.
edit: The core problem isn't so much that it requires Python and a GPOS; it's that they don't publish a spec, and instead direct you to use their Python package; the code is the spec is another way of phrasing that.
There is a full no_std Rust implementation called Leviculum, Python-free, compatible: https://codeberg.org/Lew_Palm/Leviculum
It has a lnsd daemon which runs the full stack as a native binary and some firmware implementations (like for the Heltec T114).
I think that unlike Meshtastic or Meshcore, this one is transport agnostic.
Reticulum uses attached LoRa devices, via USB for example if I'm not mistaken. It doesn't directly run on the LoRa devices.
PC not really required. 512MB of RAM and enough Linux to get Python will run Reticulum, on Raspberry Pi's for example.
There's a LoRa firmware at https://github.com/attermann/microReticulum_Firmware which looks to be fairly well supported
Why are there not more developers? Is ratspeak where they all prefer to be?
Also reticulum and crypto seem like they go together. Non-http crypto transactions?
What about entirely-non-http blockchains?
A new bitcoin that is completely off the internet as we know it??
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.
What would be the benefit of not using tcp or http ? It is used only as a way to transport binary data.
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 render a network unusable, which will inevitably happen on a larger scale.
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 absolutely prevent DoS/DDoS is to have more bandwidth than all possible simultaneous attackers, or limit physical access to the medium. Cellular networks, for example, keep direct physical access to its medium under tight lock and key through proprietary, non-open-source baseband firmware.
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.
> 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.
What's exactly the criticism you got? What do you miss?
Was also the name of the internet in Neal Stephenson's Anathem.
Yes it is.
With the Artificial Inanity systems and the Rampant Orphan Botnet Ecologies (ROBE) beginning to spew tremendous amounts of crap (a technical term) onto the Ret, things are getting tricky for us ITA.
Haha I immediately looked for this comment and wondered if the name was inspired by Anathem.
One of my favorite books that I have yet to convince any of my friends to read. So many cool ideas explored.
Unfortunately whenever I see the name, I am always reminded of part of the anatomy
I think it was named so for a reason: https://en.wikipedia.org/wiki/Endoplasmic_reticulum
personally i find it a beautiful match
Reticulum just means net or net-like structure.
I am not a native speaker, but I can't figure out what you are getting at. I have a hard time imagining you meant this:
> The reticulum is the second chamber in the four-chamber alimentary canal of a ruminant mammal.
I guess, on the internet nobody knows you're a ruminant mammal...
it'd be nice to see a comparison to rayfish.xyz
Different animal altogether.
Rayfish, Tailscale, ZeroTier, Netbird etc are a different category of tool, designed to facilitate connectivity between you and your own pool of machines. They don't generally do much in the way of multi-hop routing, but rather they orchestrate VPN tunnels on top of another routed network (like the internet).
Reticulum would be better compared to Yggdrasil, cjdns etc as routing schemes for larger networks or true meshes, which can work independently of (and have no dependency upon) the internet.
Maybe a better comparison is iroh.computer
Iroh is a framework that use QUIC to help create p2p software. It is not a mesh network.
It has nothing to do with that, like at all.
Not in a technical sense, no. But at a high level, in spirit, I can see some overlap.
In the same way that you can hack apart a loaf of bread with a spoon, yes, but they are very different things with different goals.
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 new own hubris.
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
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:
- 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
It seems like there's 14 different mesh networks that all are out there claiming to be decentralized and this and that. This is ridiculous.
We need to develop one universal standard that covers everyone's use cases.
For anyone who missed the reference: https://xkcd.com/927/
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.
No published specification, single Python implementation. Shame, as this solves a problem that badly needs to be solved well.
The author of Reticulum's take is that the implementation is the specification, so if another implementation works with the standard Python one and implements enough of it's features then it implements Reticulum.
I suppose it means it's easier to develop the protocol only having to update one Python codebase but it does mean other implementations are kinda in a state where there isn't anything to properly verify they work.
There's also a issue with quite a few vibe coded implementations that don't actually properly work filling the space.
There is a published spec, I built a clean-room implementation from it. And mine makes at least two Python implementations. The protocol itself is solid, the spec just isn't marketed.
Where is the spec?
The resistance is out there somewhere?
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.
People do use it but it's definitely a small community. It has the NomadNet Page protocol which is basically small no client side script webpages (forms and links only) in a fairly bandwidth efficient form.
[Gnomic comments go over people's heads (I'm guilty of writing these too). Gotta think in UX terms - write to make your audience's lives easier, not harder.]
You're right, and I think a lot of these projects hit the same problem: "what can this offer me that centralized platforms can't?"
Take the Gemini protocol: if someone invents a "Gemini killer app" it can be replicated over the web because the web's features are a superset of Gemini's features. Medium is the centralized equivalent of traditional blogging. Spotify is eating podcasting. The whole indie web could be emulated by Meta (it's not currently big enough for them to care). Much like capitalism eating subcultures, the existing LCD internet will consume, commoditize and re-sell all alternatives.
The only exceptions I can think of are decentralization itself (centralization can only offer an emulation of decentralization) and freedom from corporate censorship, and not enough people care about them to make the switch.
I'd love to hear counterexamples if anyone has them, because I don't like this conclusion.
> 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
Why are people developing these networks ? Who's funding these projects ? Someone knows something about the future like an internet split ?
I believe this project is primarily funded by functional autism and a sharp mind, enabled by a socially supportive environment.
It's mostly one dude who really went into the depths of it, considered a lot of details and managed to deliver a resolute implementation and presentation. Judging by the Ayn Rand quote, I believe he may ideologically fall onto the regarded side of the anarchist spectrum and may be less motivated by humanitarian aspects, as you may otherwise expect for "crisis resistant" technology. The rest of the small community seems to be made of similar libertarian type individuals, which may be one of the reasons why it doesn't gain more support). Regardless, in terms of economics, I believe the author actually decided not to play, so you may ask yourself, if you may have asked a leading question. I believe the actual answer concerning motivation is this: For the fun, the challenge and the beauty of it. It's a PoC/reference of an idea, rather than the answer to an immediate or anticipated need.
The ecosystem as a whole is a most lovely project to dive into, lot's of nuances to explore. Ideological differences aside, I am positively at awe, what the author accomplished there. Here is a spoiler, something stuck with me: A single RNode is enough to bootstrap the entire Reticulum network stack. It's web-hosting the firmware, software and documentation, everything you need, and every RNode can become a wifi access point for ad-hoc distribution. Beautiful, thoughtful feature you may merely accidentally stumble into, as it's just an understated side-note. The "it's just one guy" critique hits differently, when you see the extent of what that "one guy" actually accomplished.
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?