I don’t really like this from the Reticulum repository: “[…] The Reticulum Protocol is defined entirely and authoritatively by this reference implementation, […]”.
The reason there are so many apps trying to solve offline decentralized communications is that there’s no standard protocol or path for it. Everybody tries to sell their app as the real solver.
Also, OS-dependant (iOS/Android only apps) won’t give any progress to the state-of-the-art.
How about iOS thought third-party App Stores?
I was looking so much for an iOS app that would be worth clicking thought those scary "Do you really want to do it" buttons.
Great to see yet another project to provide "offline"-ish comms.
The existing solutions are obviously not good enough yet, hence why all these projects are popping up. I hope we get to a good-enough one soon.
LoRa is great, but the bandwidth is terrible, so you'd be limited to Twitter sized messages when using this comms channel.
Being a full mesh means an immense overhead, so well... You can't get much performances it you can't give immense bandwidth under the mesh. Though being able to exchange textual messages at a sufficient speed without any centralized infra is VERY important. In case of a real disaster we will been able to communicate at distance anyway and that's extremely valuable. The real point today is how to spread such paradigm to give enough people the ability to emergency comms.
The other critical battle is on another field: makes most people understand the opportunity and necessity of transforming the ISP's little router-server into one's own FLOSS home server with a set of services to reduce dependence on the giants, collecting one's own emails there, personal online backups of one's data/systems, to be paired with an offline one manually connected to the "central point" homeserver every evening or week, having one's own photos, contacts, ... on one's own hardware without needing GAFAM and so on.
We have for example, Umbrel, Start9, Univention, ... which more or less offer an "easy" solution; we have a certain popularity of commercial NAS units, unfortunately not exactly FLOSS and often in violation of the GPL, but we still don't have a general understanding of what can be done and how important it is to do it, starting from one's own domain name, to be citizens of the web just as one is with a postal address in the physical world.
Reticulum is a full replacement networking stack for several layers of the OSI stack, so not directly comparable. The LXMF messaging protocol (built on top of reticulum) is nice as it’s encrypted-by-requirement, but doesn’t really have a ton of non-text messaging implementations.
Reticulum is not worth getting into, the utilities and general infrastructure just isn’t there yet.
The project was basically a one-man-show for a long time, and has a lot of odd, esoteric decisions that will drive you mad if you’re actually trying to build something with it (eg, configuration files with sparse documentation that are yaml-but-not-really). I don’t mean to belittle the loads of time the original maintainer put into this project, it’s just not really designed to be usable in the general case by other developers.
I spent some time porting the reference Python implementation to no_std rust, but basically had to roll all the basic debugging utilities myself.
I was using this as a demo project for playing around with code generation tools, so it’s really not in a great state and entirely AI written, but I can share a link here when I get a chance.
My initial stab was a rust port targeting esp32 Heltec V4 (since it has some niceties like tokio) with Reticulum communication over serial, BLE, WiFi and LoRA. The serial interface was sort of working, but frankly debugging using rnsd/nomadnet was infuriating (there’s no tools just to easily see messages over the wire!).
I’ve moved onto a build system that can also target the SEEED Wio Tracker using no_std, but it’s been… messier. AI tooling doesn’t quite have the context length for big migrations like that yet.
i like it a lot, being agnostic to communication channel sets it apart from the lora only meshes. it’s cool to be able to use a mesh device to communicate with people who are both on and off the mainline internet seamlessly.
and there’s some cool stuff happening on nomadnet as well l
oh yeah and there’s a voice chat protocol that works over lora, too
> communicate with people who are both on and off the mainline internet seamlessly.
I feel like trying to do that at the protocol level might be the wrong level of abstraction. Different fabrics have very different properties. Seems like the app is the more appropriate level for seamlessly communicating via different fabrics.
Like if I try to send a video to someone but they're currently only visible to me via lora the software probably shouldn't try to push a huge blob of data over that particular medium. But I probably do want the option of sending and receiving large blobs in general, just restricted to high bandwidth connections.
Interesting project, thanks!
Seems a little complicated though? How do I set this to communicate over only TCP or Bluetooth? I think that's a common use case (where no Internet is available) yet it seems unnecessarily complex to activate.
I don’t really like this from the Reticulum repository: “[…] The Reticulum Protocol is defined entirely and authoritatively by this reference implementation, […]”.
The reason there are so many apps trying to solve offline decentralized communications is that there’s no standard protocol or path for it. Everybody tries to sell their app as the real solver.
Also, OS-dependant (iOS/Android only apps) won’t give any progress to the state-of-the-art.
How about iOS thought third-party App Stores? I was looking so much for an iOS app that would be worth clicking thought those scary "Do you really want to do it" buttons.
Great to see yet another project to provide "offline"-ish comms. The existing solutions are obviously not good enough yet, hence why all these projects are popping up. I hope we get to a good-enough one soon.
LoRa is great, but the bandwidth is terrible, so you'd be limited to Twitter sized messages when using this comms channel.
Being a full mesh means an immense overhead, so well... You can't get much performances it you can't give immense bandwidth under the mesh. Though being able to exchange textual messages at a sufficient speed without any centralized infra is VERY important. In case of a real disaster we will been able to communicate at distance anyway and that's extremely valuable. The real point today is how to spread such paradigm to give enough people the ability to emergency comms.
The other critical battle is on another field: makes most people understand the opportunity and necessity of transforming the ISP's little router-server into one's own FLOSS home server with a set of services to reduce dependence on the giants, collecting one's own emails there, personal online backups of one's data/systems, to be paired with an offline one manually connected to the "central point" homeserver every evening or week, having one's own photos, contacts, ... on one's own hardware without needing GAFAM and so on.
We have for example, Umbrel, Start9, Univention, ... which more or less offer an "easy" solution; we have a certain popularity of commercial NAS units, unfortunately not exactly FLOSS and often in violation of the GPL, but we still don't have a general understanding of what can be done and how important it is to do it, starting from one's own domain name, to be citizens of the web just as one is with a postal address in the physical world.
has anyone used reticulum and how does it compare to meshtastic (or even meshcore?)
Reticulum is a full replacement networking stack for several layers of the OSI stack, so not directly comparable. The LXMF messaging protocol (built on top of reticulum) is nice as it’s encrypted-by-requirement, but doesn’t really have a ton of non-text messaging implementations.
Reticulum is not worth getting into, the utilities and general infrastructure just isn’t there yet.
The project was basically a one-man-show for a long time, and has a lot of odd, esoteric decisions that will drive you mad if you’re actually trying to build something with it (eg, configuration files with sparse documentation that are yaml-but-not-really). I don’t mean to belittle the loads of time the original maintainer put into this project, it’s just not really designed to be usable in the general case by other developers.
I spent some time porting the reference Python implementation to no_std rust, but basically had to roll all the basic debugging utilities myself.
I’ve been looking at that exact project to bolster my embedded Rust. Is your implementation available for review? Thanks!
I was using this as a demo project for playing around with code generation tools, so it’s really not in a great state and entirely AI written, but I can share a link here when I get a chance.
My initial stab was a rust port targeting esp32 Heltec V4 (since it has some niceties like tokio) with Reticulum communication over serial, BLE, WiFi and LoRA. The serial interface was sort of working, but frankly debugging using rnsd/nomadnet was infuriating (there’s no tools just to easily see messages over the wire!).
I’ve moved onto a build system that can also target the SEEED Wio Tracker using no_std, but it’s been… messier. AI tooling doesn’t quite have the context length for big migrations like that yet.
i like it a lot, being agnostic to communication channel sets it apart from the lora only meshes. it’s cool to be able to use a mesh device to communicate with people who are both on and off the mainline internet seamlessly.
and there’s some cool stuff happening on nomadnet as well l
oh yeah and there’s a voice chat protocol that works over lora, too
> communicate with people who are both on and off the mainline internet seamlessly.
I feel like trying to do that at the protocol level might be the wrong level of abstraction. Different fabrics have very different properties. Seems like the app is the more appropriate level for seamlessly communicating via different fabrics.
Like if I try to send a video to someone but they're currently only visible to me via lora the software probably shouldn't try to push a huge blob of data over that particular medium. But I probably do want the option of sending and receiving large blobs in general, just restricted to high bandwidth connections.
Interesting project, thanks! Seems a little complicated though? How do I set this to communicate over only TCP or Bluetooth? I think that's a common use case (where no Internet is available) yet it seems unnecessarily complex to activate.