A personal summary about ideas I’ve been gathering and discussing with other community members.
Reticulum
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
Hardware
Basically readapting @Corvusboard 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.
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.
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.
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.
Ideally if you have corrections just send in a pull request to meshtastic-device/docs/README.md (which is what generates the content for www.meshtastic.org). 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.
though also kinda me