This is a collection of ideas for post 1.0 features. Based on community input we can tweak this list. Please add (but do not delete) ideas you are interested in. Feel free to add details/comments/links to the bottom of these lists, then post in this thread so we can discuss how to prioritize.
We have two approximate buckets: 1.1 features (next threeish months?) and 1.5 features (next sixish months). Mostly the focus now is on selecting which of the proposed 1.1 ideas developers actually want to work on. So please don't feel bad if your idea isn't high on this list, instead post in the linked thread and hopefully one of our volunteer devs will get excited to work on it. Or if you'd like to learn how to be a dev, we can mentor you through a GitHub issue or on our slack channel.
But of course if someone wants to work on something (even if not in this list, or if it is low) work on it and have fun. We will happily merge pull-requests as possible.
( @geeksville will probably spend about 60% of his time on these new features, and about 40% bug fixing / clean-up over the next two-three months)
Probably in 1.1:
- Implement router mode - for super long battery life / low power consumption solar nodes. (See issue #377).
- Finish RAK815 support (to prove that low ram NRF52 devices are fully supported)
- Wifi AP or STA mode support and serve up the meshtastic API on a TCP port (@mc-hamster is working on this)
- MQTT protocol/gateway so nodes(And other devices) can communicate through internet if they have an AP.(See issue #377)
- Use MQTT layer to allow remote GPIO control
- Use MQTT layer to allow text messaging gateway via the internet and riot.im.
- Any node in the mesh that has internet connectivity (via direct Wifi or via connected PC/phone) will route MQTT for other nodes. #8
- Use the new named-attribute feature to make a 'remote GPIO' on device app, for easy remote control/monitoring of GPIOs with no custom code required. #182
- Port meshtastic to the Pinetab LoRa radio (this would also allow meshtastic to run on most POSIX targets) #143
- Support totally opaque payloads, for use with really low end MCUs ( meshtastic/firmware#383 )
- Port meshtastic to very exciting boards I've been told about.
- When battery voltage falls below TBD threshold, change network params to maximize battery life and ensure we can still be contacted by radio if needed. (especially useful for solar powered router nodes) (T-Beam needs power-up default, at present they need a button press to start, not useful for unattended repeater)
- Add power profiles to the device, which can be set from the android app. See Issue 389 - A small number of presets to simplify the selection of the device's power saving features.
Probably later:
- iOS client (probably via Flutter?)
- Implement a 'I need emergency help button' #60
- Make a new 'geofencing' on device app, which messages when a node enters/leaves a place. Could allow very long battery life for animal tracking.
- Store and forward messaging - If the mesh gets fragmented or a node goes out of range for x-period of time, eventually deliver the messages to the node that has rejoined. Especially useful for the hiking use case because someone may be over a ridge and have lost the Line of Sight.
- TTGO v2.0 2.1 navigation buttons soldered on the board(ability to customize button GPIOs via preferences)
- Extend the portduino simulator to run whole meshes of nodes in simulation.
- Enable a specific node in the mesh to log all position packets to a file (either in the App or SD card on device) to allow post activity route analysis of each node
- Buzzer support: Beeps for message received, node join, low battery etc
- Let user subscribe to multiple channels at once
- show compass heading in degrees as well as arrow. Makes it easier to track the true direction of a person in distress.
- add text-to-speech option in the app, for hands/screen free monitoring (while busy with stuff) and warnings of system events (new node discovered, low battery etc...)
- add speech-to-text to the app, now it can be used almost as a normal phone.
- External buttons - Have firmware recognize several exposed GPIO pins for 'scroll', 'event', etc. so that external mom.spst (reed sw, mercury sw. etc) can trigger these events. At present, we must expose device to the elements, or manufacture weatherproof actuators (difficult).
- Let app distribute APKs of itself over Bluetooth or Wifi: per this forum post. let the device distribute the app or have a Wifi web client for basic use for any Wifi enabled device.
- Rearrange tabs on screen and add sorting option by name, range, battery, etc. See Issue 387
- Keyboard feature: Either connect a Bluetooth or I2C cheap keyboard or use T-Beam buttons to select characters(One button select letters A-Z and the other one is the Next button.If you hold the next button down it will transmit the message)
Probably much-much later (or never? unless someone wants to do this):
- Code to support TTGO T-Dear mini, TTGO T-SOLAR, Lora32u4 II, Heltec Cube.Features: Recognize a relay in the nodeList as a relay.Ability to redirect all channels or only a list of channels.Have an owner password in order to change settings on the go(Like allowed channels name and battery status usage view etc).It should have a mode that it's used by the owner to map it's range. (@geeksville comment: I know of a couple of upcoming products that I think will make all of these 'ASR6505 based' low RAM devices obsolete. i.e. same price (approx), much more RAM and flash, even lower power consumption. So I don't recommend spending much time on this idea)
- Implement TTN LoRaWAN communication for messages and for 'I need emergency help button' #60 #377 (@geeksville comment: I think once we add our MQTT gateway/routing feature, there is minimal need for this case - given that TTN coverage is far lower than what meshtastic can achieve by letting any node gateway if it can get Wifi or 4G)
- Stealth Mode: Fully disable GPS and location services to increase privacy. (I think this is already mentioned somewhere, can't find a link)
Not user visible but useful for the future.
Probably in 1.1:
- Clean up the device code - make the 'mesh' layer a separate library. Split the current GUI into an on device 'app'
- Minor code cleanups, bugs #108, #107
- Portduino: meshtastic for base POSIX (non Arduino) systems.
- Add real power-on and factory diags, to detect failed hardware #128
Probably later:
- Report device crashes via the android analytics pipe
- Revisit the power measurements on ESP32 and NRF52 and re-tune, confirm new battery life
- Use the MQTT gateway to let users (optionally) upload signal strength and position info, so we can build a corpus of real-world measured radio performance
These are ideas for the Android app. If anyone wants to make an iOS client (possibly based on Flutter @geeksville is happy to help you succeed)
Ideas for the meshtastic App development
Probably in 1.1:
- Make a tablet specific layout (I forget the bug number) - that shows map and chat at the same time
- Enable landscape layout (I forget the bug number)
- Tap on failed message to re-send them
- Implement Ping button for each node in the app list in order to refresh details about the position and the signal strength.
- Display nodes RSSI connection status with other nodes (It would be cool to see the RSSI on the map for each node from the entire network(This can be called to diagnose the network and has to be done through a button press in order to get this info when it's needed).This would help to extend coverage in the area)
- Notifications when node joins your network.
- Set Wifi SSID PASSWORD, MQTT SERVER IP, power profiles #389 from the app. Probably best done by using reflection to get various settings names.
Probably later:
- Whatsapp Style communication system with full name display and correct message positioning(Sender's messages in the right and receiver's message in the left)
- Different icons for different node models, different icons for the nodes that are connected to the internet to suggest internet and MQTT connection, also more info on the "People" section(second tab from the left): RSSI, Board Info, Wifi Access, MQTT Access.
- Allow the sharing of static GPS Waypoints that would be plotted on the application map such as: Meeting locations, First AID, Water source, Vista, etc.
This is the next big bucket after 1.1. Probably dropping about six months from now. Biggest work item is probably switching to qmesh or reticulum as our transport (or possibly staying with the current transport and optimizing).
- Use an alternative routing protocol (Reticulum, QMesh) #192
- Fully implement DSR for unicast messages #3 (if we don't switch to a different transport)
- Allow nodes to route for channels they don't have the encryption keys for
- Programmatically limit duty cycles for regulatory compliance
- Since nodes have GPS time, leave all receivers (and CPUs) completely off most of the time - then once every 30secs, wake and check to see if anyone is transmitting)