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

[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

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

[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