Input on the direction of Reticulum in 2025

[markqvist]

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

• RNS Core
  • Improving rnsd storage backend
  • Memory optimisations
  • Improve packet processing speed
  • Optimise IO performance
  • Dynamic interface authentication (per-user/per-device authentication)
  • Distributed destination name resolver system
  • Intelligent metric-based path selection based on medium and topography conditions
  • Network-wide path balancing and multi-pathing
  • Creating external language bindings against the reference implementation to easily allow developers to use Reticulum in other languages, and to automate testing of new implementations against the reference implementation.
  • Expand automated unit and functional testing significantly
  • Add interface hot-plug and live up/down control to running instances
  • Add automatic retries to all use cases of the Request API
  • Globally routable multicast
  • Destination proxying
• User-facing
  • Community net/interface announcement system running over Reticulum making it possible for users to discover and connect to existing networks
  • Documentation
    • Rework several manual chapters
    • Restructure manual for more intuitive use
    • Incorporate community-contributed documents into the manual
    • Create a developer-oriented introduction guide to the concepts and functionality of Reticulum
    • Formalise protocol spec and include in manual
    • User-facing knowledgebase built on the Diataxis framework
  • Standalone RNS daemon app for Android devices
• Maintenance
  • Upgrading and restructuring the testnet
  • Ongoing package maintenance, bugfixes, etc. of all relevant packages
  • Guiding and providing support to different teams currently creating implementations of Reticulum in C, C++, Rust and Zig.
• Application-layer protocols
  • Implementing group chat in LXMF
  • A genereic http-like resource transfer protocol
  • Real-time voice protocol
• Device and hardware support
  • Reticulum transport node images for Pi
  • RNode firmware running under Linux / embedded linux for low-power SBCs
  • Direct SPI LoRa driver / interface module
  • OpenWRT packaging
  • Adding support for more communications mediums and devices
• RNode
  • Improving ease of build process / flashing
    • Refining the process for both the CLI flasher and web-based flasher
    • Creating much better step-by-step documentation for the process
  • Rewriting RNode CSMA to more efficient method
  • Improving interfacability with host systems
  • Adding support for new transceiver chips
    • Semtech LR1100
  • Expanding hardware support to more devices
    • Heltec T114
    • Lilygo T3S3 SX1280
    • Xiao32-based devices
    • Lilygo T-Echo
    • Heltec Wireless Stick
    • Sensecap T1000
    • SenseCAP Indicator D1L
    • MeshAdv-Pi-Hat
    • WaveShare SX1262 Pi hat

[simplyequipped]

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.

[NHOQA]

adding another +1 for group chat functionality

[fr33n0w]

+1

[kc1awv]

I just wrote an ephemeral chat room implementation into RetiBBS, currently running on Kaizen. You're welcome to test it out!

[joakim]

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

[skyguy]

Based on your list - it looks like funding a team of developers should be the first focus!

From your list, I would prioritise:

• Formalise protocol spec - to ensure other implementations implement the same behaviour
• Expand automated unit and functional testing - (Use 'pytest' to make testing easier?)
• OpenWRT packaging - more devices = more participation

I'd like to add 2 areas I think are important:

1. Adding a version field to the wire protocol & planning for future change

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.
By adding a version byte set to 0x0 and code to forward all other packets to all neighbours, we can keep the network running when a protocol change needs to happen. This might become especially important when thousands of devices are deployed in hard-to-reach places, possibly running other implementations.

2. Protecting the 'first hop' over the Internet

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.
I would suggest renaming the current TCPInterface to TCPRawInterface and implementing an encrypted stream TCPInterface.

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.

[plongk]

1. group chat
2. real-time voice

[trosel]

Also, multi-device support

Desktop and mobile using same identity somehow. No preference on how that is achieved though

[mntn-xyz]

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.

[joakim]

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

[resession]

real time video protocol

group to group destination (many to many)

[HotMicSystems]

RNS Voice-Would be amazing to be supported natively, we have seen what is possible with MeshChat from Liam as an example.
Intelligent metric-based path selection based on medium and topography conditions- Very Big in terms of reliability and robustness of the network under dynamic conditions(I think I posted a discussion about this). Hopefully this feature does not get over looked by the community because this is very much needed. Thanks again Mark and the other contributors! Looking forward to 2025!

[DayleDrinkwater]

+1 multi-pathing.

It would be cool to have graceful failover for a link, or even multiple links?

[zelea2]

• Re-writing in C and removing Python dependency will open the door for a lot of embedded platforms.
• Voice transport app for the Android platform will help a lot of people living under oppressive regimes in the world.
• I would also like to see RNode support for LILYGO T-Beam

[fr33n0w]

external app tunneling through Reticulum would be great!

[ducksandgoats]

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 reticulum://. for now i took a look at the websocket server that meshchat provides. but reticulum/rns already provided some mechanism for external apps then that would solve it much quicker and better.

[trosel]

User-facing
Community net/interface announcement system running over Reticulum making it possible for users to discover and connect to existing networks

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.

[joshbowyer]

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.

[markqvist]

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 :)

[LinuxinaBit]

Here is what I, personally, would like to see prioritized in 2025:

1. Hot-pluggable interfaces
2. Multicast/multi-hop group destinations

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 reliability

[LinuxinaBit]

For the record, the ‘group chat’ functionality everyone wants would depend on this native Multicast for it to be efficient in any way, but implementing Multicast does not mean Reticulum-based decentralized group chats would instantly become a reality.

[joakim]

Having struggled with this all day, I can give a big +1 to this:

• Improving ease of build process / flashing

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:

• Group chat in LXMF
• Reticulum on embedded systems (C/Rust/Zig)
• Reticulum transport node images for Pi (I half expected this to exist)

I also like LinuxinaBit's proposed theme, not that I don't think it is already :)

[cannon-c]

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
Encrypted group chats would be very beneficial and would obsolete other protocols and the need to use other chat applications.

Real-time voice protocol
My pursuit of secure communications is what originally brought me to Reticulum, LXMF texting capability would be very well complimented by voice communications. I'm currently using LXMF for encryption over satellite phones, but this is only limited to text based messages for now. Satellite phones are very useful but lack encryption, there exist no open source solution for P2P encrypted communications over phones or radio, reticulum can be it. (No, Signal App is not P2P, and not decentralized, and requires use of phone numbers). Voice call support would really be useful in being able to have encrypted communications not limited to just text based messages. There are times in which voice communications are important or have benefit over text.

An implementation in another programming language such as C++ or rust
Python applications are usually very dependency heavy and with massive dependency trees. And it is really difficult to build things from source code in python. Due to the large dependency trees in python, python based applications are at a heightened risk of supply chain based attacks and can be difficult to audit, and usually difficult to build the dependency tree from source code. Open source is important, but the benefits of open source only come if someone actually builds it from source code. For this reason, I am personally a fan of other programming languages that are low on dependencies or encourage and make the ability to build from source easy. If reproducible builds are possible, that is like the perfection of open source transparency, the verification of building from source without the complexity.

[cannon-c]

(just finished alot of edits to my post)

[KenSamson]

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.

[markqvist]

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 :)

[KenSamson]

Very nicely done!

I've never tried an install of Grafana.... it looks good...