Input on the direction of Reticulum in 2025 #659
Replies: 20 comments 20 replies
-
|
Another exciting year ahead for the Reticulum community! +1 for LXMF group chat and C/C++ Reticulum transport node implementations for embedded platforms. I plan to work on additional HF soft modem interface options this year. JS8Call is working via pyjs8call, and I am actively working on a similar interface for Fldigi. I also plan to produce a new handheld RAK4630-based RNode (tentatively referred to as the RNode Pro) this year that is weatherproof and supports solar charging. First hardware prototypes are being produced now, with much testing to follow. |
Beta Was this translation helpful? Give feedback.
-
|
adding another +1 for group chat functionality |
Beta Was this translation helpful? Give feedback.
-
|
+1 |
Beta Was this translation helpful? Give feedback.
-
|
I just wrote an ephemeral chat room implementation into RetiBBS, currently running on Kaizen. You're welcome to test it out! |
Beta Was this translation helpful? Give feedback.
-
|
+1 for C/C++/Rust/Zig implementations for embedded platforms. I think Python was a great choice for a reference implementation, but it feels like now is a good time to go embedded, considering the popularity of devices like T-Deck. |
Beta Was this translation helpful? Give feedback.
-
|
Based on your list - it looks like funding a team of developers should be the first focus! From your list, I would prioritise:
I'd like to add 2 areas I think are important:
Over time things will need to change, so we should prepare as much as possible. Curve25519 might be broken, keys might need to get bigger, ciphers might need to be swapped out.
Sender Anonymity is an important feature of Reticulum and possibly a large drawcard for participation. However the current implementation doesn't provide this feature for anyone who connects over the Internet for their 'first hop'. Anyone packet-sniffing a well-known Transport Node is be able to log the source IP address for every Announce. Putting my money where my mouth is - I'm currently getting familiar with the codebase to implement both these suggestions, hence my suggestion to focus on expanding testing! Thank you for creating and releasing Reticulum - it is an interesting and (I believe) important project. The Reticulum network already seems to provide a working, viable network where so many other projects are vapourware or abandoned. |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
Also, multi-device support Desktop and mobile using same identity somehow. No preference on how that is achieved though |
Beta Was this translation helpful? Give feedback.
-
|
It would be interesting to explore a graphical client (with Sideband-style capabilities) on ESP devices that include screens and keyboards. The LilyGO T-Deck is a good candidate, and/or the Cardputer. If these don't have the horsepower then I just came across an in-development ESP32-P4 device that includes a keyboard, WiFi, and a LoRa radio; it isn't available yet but something like this would be a good devkit for an off-grid communicator. With any of these, LVGL could give you a nice UI on a portable device without needing to run a full OS. |
Beta Was this translation helpful? Give feedback.
-
|
Similar project, but ESP32-S3 and e-ink: https://cl-32.com/ I think we'll see more pocket computers like this in the coming year. Perfect for wireless communication on the go (Bluetooth LE, WiFi and LoRa). |
Beta Was this translation helpful? Give feedback.
-
|
real time video protocol group to group destination (many to many) |
Beta Was this translation helpful? Give feedback.
-
|
RNS Voice-Would be amazing to be supported natively, we have seen what is possible with MeshChat from Liam as an example. |
Beta Was this translation helpful? Give feedback.
-
|
+1 multi-pathing. It would be cool to have graceful failover for a link, or even multiple links? |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
external app tunneling through Reticulum would be great! |
Beta Was this translation helpful? Give feedback.
-
|
this would be great! like the tor daemon. on my app, i can use a local server/proxy localhost:9050 to send traffic through the tor network. if reticulum had some way where i can send traffic and interact with reticulum data then i can use reticulum on my app with a protocl handler like |
Beta Was this translation helpful? Give feedback.
-
I think this is the most important thing. Now is the time to get more users, dare I even say "normies" on Reticulum. Because that will allow you to get a better sense of every other priority. We will be able to see and feel where the pain points actually are. Even if it means not using Reticulum "as it is intended" (like just throwing everyone on one giant network together), it will still be the best way to see where the pain points are. |
Beta Was this translation helpful? Give feedback.
-
|
Chiming in on the support for MeshAdv/Waveshare hats, you could do it similar to the way Meshtastic does it, and just support sx1262 (amd maybe lr1121 or a few others?) over spidev. Then in a config file define the pins for reset, busy, irq, and if applicable, rxen/txen. Would simplify writing the code, and allow for variety in hat designs. |
Beta Was this translation helpful? Give feedback.
-
|
Thank you so much everyone who has contributed to this discussion so far! I've read everything, and taking it all into account. I won't respond individually to every reply here, since that will take all day, but please do keep the input coming if there's more to say. I'll try to take all of this into account and create a revised and semi-prioritised version of the above :) |
Beta Was this translation helpful? Give feedback.
-
|
Here is what I, personally, would like to see prioritized in 2025:
Those are the two most important features that Reticulum needs before it can be considered ‘complete,’ the rest is relatively extraneous. For a ‘theme’ this year, I would like to suggest |
Beta Was this translation helpful? Give feedback.
-
|
A bonus 3rd one, as suggested here, is message delivery confirmation for propagation node messages. I think that warrants some thought as well ;) |
Beta Was this translation helpful? Give feedback.
-
|
Having struggled with this all day, I can give a big +1 to this:
It would make "Expanding hardware support to more devices" by contributors much easier. I'm very new to Reticulum, but these sound good to me:
I also like LinuxinaBit's proposed theme, not that I don't think it is already :) |
Beta Was this translation helpful? Give feedback.
-
|
Alot of great things noted here. A few things that stood out to me that I personally find of importance. Implementing group chat in LXMF Real-time voice protocol An implementation in another programming language such as C++ or rust |
Beta Was this translation helpful? Give feedback.
-
|
(just finished alot of edits to my post) |
Beta Was this translation helpful? Give feedback.
-
|
I have a few ideas that may not make it to the top of the list, but may get entered into the overall pipeline: For transport nodes and content nodes like nomadnet serving up information and other LXMF nodes, allowing key information from those network nodes to be gathered into something like https://opentelemetry.io/ so that one can see the volume of information and reliability/uptime/throughput of the links could help in managing a growing network. I'm not convinced we really want to use an IP hosted server, but the content of a telemetry server is already quite alive, we would just need to expand tags and values and enable nodes to send in key telemetry for analysis. If you have ever had to manage the movement of information from an ops perspective, something like https://oss.oetiker.ch/mrtg/ eventually becomes very handy. Since that is not a one-sprint journey, we should start very small and grow organically with what is useful. (Link uptime and link data transported stats could be useful, just like rnstatus gives already.) Clearly one should only send telemetry of any kind to a trusted node. Given that LXMF servers already know how to use an access list, creating a storage directory for larger files (I'm thinking a few meg, not terabytes here) to be served out of a directory that has it's own access list and perhaps even it's own LXMF address for that data store could pave the way for a distributed content capability. We would need a way to query the directory of the content using it's LXMF address, and then the client would need a way to request that one of the files in the data store is served up. Sync timings could be set like like LXMF synchs are, and files could be distributed at off-hours from a network traffic perspective. I think they sit there with localized encryption on the LXMF server, and then they get encrypted specifically to the endpoint that requests them as they are sent. The files would stay encrypted to the endpoint that subscribes to them until explicitly saved outside of the client, so all data sits as encrypted in the client. Nodes would have to have config entries for which LXMF data stores to replicate, and local access lists for who to allow to see them. What I'm less clear about is how this would get 'advertised', but non-central and replicated data stores is a natural next step. Maybe it's like announces... it only gets propagated to nodes where clients have asked for that LXMF data store to list the contents... and then that transport node starts to ask around for who might have it.. first close, then farther. (The ask only lives one hop, then two hops, then three....) Then if that data store is not accessed, replication gets slowed down and stopped, as there is no need to move data around that is not used, and it is retired as it gets (config) age old. The access list for a given data store could have an admin entry in the config file, and then that admin could update the access list, and then that access list would then get propagated like any other file. And just like that, LXMF Cloud was born. We may want to relegate this replication traffic to a subset of the traffic on the network, similar to announces, unless a link is not very clogged. There are lots of directions this could go, such as designated replication pairs in the config file, etc. I would love a way to have a telemetry server store the telemetry into a sqlite database that I could use a command-line decrypt tool to dump the contents into a non-encrypted sqlite database. I would then have a record of the telemetry over a window of time. |
Beta Was this translation helpful? Give feedback.
-
|
Something like this? :)
That's my stats dashboard for one of my Transport + LXMF Propagation nodes. All of the telemetry for that is transmitted and collected completely over Reticulum (using the telemetry functionality of LXMF). It is then delivered to a locally running InfluxDB instance, and graphed with Grafana, no IP networking required. Thanks for your thoughts on everything in the post, all noted :) |
Beta Was this translation helpful? Give feedback.
-
|
Very nicely done! I've never tried an install of Grafana.... it looks good... |
Beta Was this translation helpful? Give feedback.
-
|
I am looking forward to |
Beta Was this translation helpful? Give feedback.
-
|
+1 for :
|
Beta Was this translation helpful? Give feedback.
-
Does that have anything to do with sharing LoRa connection parameters? (like frequency, bandwidth, spread, coding) Or is that about something different? I think the ability to discover what channels/settings are being used locally without the need for existing comms infrastructure would be a huge boon. Maybe a scanning mode that spends all its time channel hopping is doable, but also while connected if data is retransmitted when not acked, then maybe there's enough time to briefly channel hop at an infrequent interval and listen for traffic without an ongoing connection from being interrupted with too much dropped packets. That would be the main thing on my wishlist, I love projects like this and meshtastic, but I end up only using it between my own devices. I think it would be fun to relay local messages to extend their range but that would require getting in contact with local people to coordinate settings. Not to mention in an off-grid scenario without regular comms you would have to have coordinated settings beforehand. An automatic mechanism to broadcast and scan for shared radio would be incredible. |
Beta Was this translation helpful? Give feedback.
-
Yes, exactly that, and also all other kinds of public interfaces you could imagine, like TCPServerInterfaces, I2PInterfaces, and so on. Thanks for the input. |
Beta Was this translation helpful? Give feedback.
-
|
Any plans on supporting GPS advertisement, similar to how Meshtastic can show the location of nodes? |
Beta Was this translation helpful? Give feedback.
-
|
So the other discussion is obsolete now. |
Beta Was this translation helpful? Give feedback.
-
|
I didn't read the whole thread, but Sideband does have something similar. That is, it gets the location from the OS (GPS on mobile) and shares it securely over Reticulum. I haven't used the feature myself, but that's what it says on the package :) |
Beta Was this translation helpful? Give feedback.
-
|
It's not GPS advertisement (very much on purpose), but Sideband's telemetry system does allow sharing of GPS data over Reticulum: |
Beta Was this translation helpful? Give feedback.
-
|
thanks for the resource @LinuxinaBit! So it looks like GPS is possible and it is done with the Sideband app, rather than having this telemetry directly on the RNode. It's much more clear now. 🙂 |
Beta Was this translation helpful? Give feedback.
-
|
Yup. In the future this may be doable with microReticulum, but right now microReticulum is only really able to serve as a standalone Transport Node (still very impressive in its own right). |
Beta Was this translation helpful? Give feedback.
-
|
For me most important:
|
Beta Was this translation helpful? Give feedback.
and others
-
Hello everyone! In setting the course for the overall Reticulum project in 2025, I'd like to invite everyone in the community to provide their opinions on what areas are important to work on.
I already have a relatively large list of areas that I deem important to improving and moving the project along, and have included a loose outline of my current (relatively unstructured) plan for work in 2025.
If you feel like things are missing from this, if you have great ideas, important issues, or any kind of input, please share them, and let's have a discussion about where the community would like the work to be focused.
Project Plan Draft
RequestAPIBeta Was this translation helpful? Give feedback.
All reactions