TODO list after 1.0 suggestions - IMPORTANT

[retrodime]

I had prepared some important suggestions and ideeas that should be a priority after 1.0.

1. Wifi support:

First Release v1.0 - EXPERIMENTAL; CRITICAL TO HAVE:

    - Implementation of a wifi connection attempt with error handling and reattempting to connect
    - Configuration of the wifi AP should be done in a specific file configuration.h
    - We don't focus on power management at this stage, we care about building a stable network arhitecture that will reattempt to connect in the background if something fails.

Second Release v1.1:

       - Fix Bugs + Code Optimisation of the previous Version
       - Implement small experimental Delays and power management ideeas
       - Focus on stability
       - Display Details on Oled(Network SSID + Signal Strenght)
       - Small Documentation throught code comits

Third Release v1.2:

      - Bugs + Code Opt
      - Improuve the power management of the wifi protocol
      - Focus on DEPLOYMENT

Fourth Release v1.3 - DEPLOYMENT:

     - Fix Bugs+Codes+ Compatibility issues
     - App update to setup the wifi settings throught Meshtastic App(Specify Power Management Options, SSID, Password)
     - Documentation

Release v1.4+:

      - Major bugs Fixies + Optimisations
      - Power Management Improuvements
      - Ability to setup multiple Acces Points + Passwords (The device will attempt to connect to all of them until a connection is made)
      - Better Doc

EDIT: It would be cool if 2 nodes are connected to the same wifi, they will communicate throught wifi instead of lora to save some resources and make communication faster.More issues found here: #375

2. Messaging Server
- Usefull for uploading/downloading messages and make a longer connection with remote nodes
- Can have an API in order for other non-lora devices and software to be able to read/send messages

First Release v1.0 - EXPERIMENTAL;CRITICAL TO HAVE:

       SERVER:
       -Setup new Github Repo
       -Basic server using Nodejs and Express

       BOARD:
        - Ip + Port Specify in configuration.h
        - Upload/Download Timeout setting
        - Server section will work only if a wifi connection is made

Second Release v1.1 - Stability:

         SERVER:
           - Code optimisation + Bugs
           - Implement small security benefits such as username/password based autentification (This will be optional)
           
          BOARD:
            - Write code to support the autentification arhitecture
            - Small power management changes

Third Release v1.2 - Security:

         SERVER:
            - Code Opt + Bugs + Crash Handle
            - Channel inside the Server(Every device will send the Channel Name and the server will Sync messages only for device with the same channel)

          BOARD:
            - Write code to support the new arhitecture
            - Optimisations+ Other ideeas here

Release v1.3+:

             - Api for the server
             - First community server hosted on a free tier aws EC2(Yay, we will be able to chat)
             - Documentation
             - Setting the server details near the wifi section
             - Boards won't connect to an AP if they don't have a server specificated
             - Power Management tactics in case the Server is unavaible

EDIT: More issues regarding a server are posted here #169 #353 #374

3.Repeators:

        - Ability to set the device to REPEAT-ONLY mode
        - Open source arduino code for other LoRa devices that can only be used to repeat the signal 
        - Repeators devices that are capable of wifi will attempt to deliver messages to the server specificated by the node or to a server that is stored in their config - TO BE DISCUTED
        - Wifi repeators will also download messages from the server and repeat them to the nodes

• It would be cool if we can connect other devices to the repeator or to a mestastic node that are only capable of Lora in order to send and receive messages(Usefull to send commands to nodes and read sensor data).As security each repeator can have a special configured Key for AES and the nodes must have the same key in order to comunicate with the repeator.A dummy arduino code would be cool to show how to connect to a meshtastic network.Even if this not the scope of the project, it may come in handy for some of us.I know that there is the TTN network for this, but it cannot have repeators and because it's a public network, it comes with a lot of limitations.Here you can host your own server and have your own channel group.You can basically specify the limits of how many messages you wish to transfer/download.

Edit: relevant info can be found here #158

4.LORAWAN and the TTN network:

• Such a huuuge network, why we won't use this? Meshtastic is a communication protocol, so it would be cool to try and send emergency messages to the TTN newtwork.I don't have much experience with this protocol but I know you nedd 2 keys to autentificate to the network.You can pre-set them on the board memory and when it's the case you can switch the mode to the TTN network and you could send normal chat on the TTN.I think you cannot receive messages from a gateway, but you can have a server or something setup that will connect to their API and forward your messages to a service or to a person or if you wish it can even forward messages to the community server if we will ever have one.But basically meshtastic should have a TTN option as well.

Edit: Regarding to #60 it would be cool to also use TTN to send emergency message after it had sended normal Meshtastic alert message.

Now, the most important ideeas are the 1. and 2.Later it may be usefull the 3. and 4.
I don't know programming and other stuff but I can imagine in teory how this can work.....also I read some suggestions and I just placed them here.....I just hope that they can be implemented at some point

[AlloryDante]

Omg, I really really hope that this is the future of Meshtastic.This may become one of the most important projects involving Lora.Personally I also find the Wifi and the MQTT server a must have, and it should be a priority right now.

As an ideea for the repeators, it would be nice to make them somehow accesible to the public if you want.For example it would be cool if someone else can transmit an encripted message signed by the mestastic network with an identifier and that repeater will transmit the same encrypted message over the air, if it has been configured by the owner to do so.Or it can repeat emergency signals in case something happens.A further discution is required here, but basically I want to see the mestastic network like a LoraWan network but for sending messages also open for public if the owner of a repeater decide so.

[retrodime]

@cezarlacatus Thank you for sharing your ideeas.
@mc-hamster Take a look at those ideeas

[dc-cooper]

Wow so cool, hope @geeksville would agree to add this in the future.I just discovered the project today and I personally love it.It has a potential.

In my oppinion the repeator should be divided in 2 parts: a dedicated repeator(That can be open source and can only repeat encrypted messages that are coming from the meshtastic network) and an included repeator.The included repeator has to be integrated in any board running the meshtastic.You will specify a mode Repeat-Only and you can have 2 options: Repeat everything or Private Repeat.Repeat everything will allow the encrypted message to be repeated from other Meshtastic users that are in another channel and Private Repeat will allow repeating of messages that are coming only from the owner group.

A dedicated repeator can look like this: https://youtu.be/uZkGudvjNzw .

We should try to achive SMS style communication over the world.This is the purpose of this project, and we need to use everything that we can get in order to do that.Even Wifi ,MQTT open source servers , Repeators and yeah for emergency the LoraWan network, as it is verry extended.

So I agree with every ideea listed here, and I think this is a must have for the project, as it can not only save lives but It makes private communication more secure and fun.

[mc-hamster]

@retrodime geeksville is maintaining the roadmap at : https://github.com/meshtastic/Meshtastic-device/wiki/1.1-1.5-feature-list-ideas

I'm almost done with the functionality for a WiFi Client. After that, working out a bug and then will start on a WiFi Software Access Point.

[geeksville]

A lot of good comments here (and sorry - I was away from my github notifications for a couple of days):

re: connecting to the internet
Yep - the wifi connection stuff MC is doing will get us much of the way there.

re: generalized IPC and messaging
Our task to add a MQTT layer I think will do most of this. When any meshtastic node can reach the internet it will provde mqtt gatewaying for all other nodes in the mesh. I will be working on this soonish.

re: TTN
I initially did a fair amount of experimenting with TTN. And I gather coverage in Europe is much better? But here in the US (where I am currently) coverage is nearly non existent. Even in geek-heavy silicon valley there are only a few gateways (including one of mine) and coverage is marginal.

This is part of why I think our own "just let meshtastic nodes gateway to the internet" via either:

• the helper app (android or python or eventually iOS)
• directly (for ESP32s that have wifi)
• Satellite or 4G gateways might work and are being experimented with by folks

[mc-hamster]

Closing this request. Most of what is in here is already done or in progress in another ticket.

1. Wifi support: - This is Done
2. Messaging Server - Covered in a MQTT request
   3.Repeators: - This is done
   4.LORAWAN and the TTN network:- If this is required, please open a new request for just this.