Ideas for future developments: a recap

A personal summary about ideas I’ve been gathering and discussing with other community members.

Despite still in alpha since 2018, Reticulum poses itself as a game changer in LoRa-based networks. Its approach resembles OTR (off the record messaging) featuring perfect forward secrecy, self-pairing and configuration, anti-tampering and easily allowing to switch from LoRa to BLE or WiFi as transmission medium.
A con is that it needs at least 1kbps, probably a bit less if properly configured. Super low-speed data transmissions would be left over.
Read more

Basically readapting @Corvus board to Meshtastic needs. It will support solar charging, safe discharge, thermal management (thermistor or fully-fledged environmental sensor like the AHT11 or BME280 to monitor for possible leaks) and fuel gauge.
Other possible additions are:

  • a microSD card holder to store Reticulum cached handshakes
  • a GPS for (positional) anti-tampering and accurate clock sync
  • RTC (less power-hungry than GPS)
  • NFC support for fast pairing

Remote management
As headless nodes will generally be quite far from each other, a way to remotely monitor and manage their settings could be very handy, by either transferring the whole config file or just a single param (wifi:true, ble:false). Mavlink protocol can be source of inspiration.
Read more

State of charge dependant behaviour
Expanding @myself248 idea, Meshtastic nodes can have different behaviours according to the battery power. If over a certain threshold, they act as repeaters, otherwise turn into a quiescent mode waiting for user input. Obviously headless repeater nodes won’t have such feature.
Read more

BLE/WiFi escalation
If a cluster of nodes happens to be within a certain geographically-limited area, the inner nodes could switch to a faster communication medium such as BLE or WiFi.


btw - the qmesh author also had a good idea related to this:

Just wanted to add a few details regarding Reticulum. The requirement for 1kbps is not set in stone, a few hardcoded timing assumptions depend on it currently, but it was always my intention to dynamically allocate those timings before moving out of alpha anyways.

There’s a usability consideration to this as well though, since on very slow links, like 100bps, the initial key exchange (announce) and link setup would take a long time (probably around 45 seconds, if I remember correctly). It should be possible to do that on a faster channel though, and then switch the link to a slow interface afterwards.

Another note that might be of interest to you is that the current Reticulum implementation in Python will serve as a reference implementation for a version written in C or Go, so it will be possible to include as a library for microcontrollers and embedded devices.



Send a sync signal across the whole mesh network at a certain time to find out new nodes as well as map those ones that are still working.

PPT Voice Transmission
Use a special compression algorithm supporting low datarates to send audio over LoRa
Read More

Has someone already suggested to add a function (command) that will be broadcasted to another node that triggers an external action.
So as to switch on some device/led/sensor not necessarily connected to the TTGO.
Kind of an extension of the sound buzzer for events as new messages.

For headless nodes. NFC for fast paring would be nice. However we could also consider having usb paring as an option, by having the phone connect to the node over serial and querying the paring key via that.

Plus it would allow for the app to provide node update feature to keep the node up to date with the latest version.

Or to dump bug report to meshtastic team

Ive been going over the API and I think there is a GPIO method, not 100% Im interested in using it as a sensor myself and being able to close a relay or the like remotely would be cool.

You can press the middle button twice while paring and it changes the code to 123456. Ive had to do this for my screenless units.


Ah will try that. The instructions in the main website was not very clear. Who deals with the website? Really should be updated.

I think we all do :wink: though also kinda me :wink:

Ideally if you have corrections just send in a pull request to meshtastic-device/docs/ (which is what generates the content for If you have questions about how to generate your first PR I’m sure someone here will help.

I believe in the thread of mesh routing, which is eager for your contribution, we reached a similar solution to the pathfinding algorithm to Reticulum.
I strongly believe that if we improve the delay function in page 7 step 1 we can have a very compelling algorithm!

I looked at some source code and felt very standardized, I am very happy, but understanding the overall running structure of the code in a short period of time is difficult for beginners, because there are too many, I hope to draw a logic diagram or flowchart, function process diagram, these can be used, describe the relationship between each file.