MQTT WIP

docs/software/TODO.md

@@ -55,18 +55,22 @@ You probably don't care about this section - skip to the next one.
 
 * DONE have sim provide a fake wifi connection status saying connected
 * DONE don't start MQTT if we don't have wifi connected
+* have plugin send uplinks from mesh
+* have plugin send downlinks to mesh
+* don't decrypt messages before uplinking them to MQTT (move out of plugin)
 * mqtt.meshtastic.org should have VERY basic auth at launch (to prevent abuse)
 * make a GlobalChat channel as an initial test (with a well known AES128 key), figure out how globally unique IDs work
 * Give place in android app for users to select which channel they are sending on (and which channels they are watching)
 * attempt reconnect to server if internet connectivity changes
 * don't bother contacting server if we don't have any uplink/downlink channels
-* test on ESP32
+* DONE test on ESP32
 * no need for python gateway to web initially: because both the simulator and ESP32 can talk wifi directly
 * if simmesh_name is set in preferences, create the MQTTSimInterface using that as the global channel_id
 * figure out how to use MQTT for simulator mesh network, use a special simmesh_name global channel_id? (because this would allow all nodes in simnet_xxx to subscribe only to those packets)
-* do initial development inside of portduino
-* do as much possible on the device side (so we can eventually just have ESP32 talk directly to server)
-* add mqtt_server to radio prefs
+* figure out legality of hosting public mqtt servers with chat msgs
+* DONE do initial development inside of portduino
+* DONE do as much possible on the device side (so we can eventually just have ESP32 talk directly to server)
+* DONE add mqtt_server to radio prefs
 * eventually add a MQTTPacket on the ToRadio & FromRadio links
 * LATER: an android gateway would be useful
 

docs/software/mqtt.md

@@ -70,19 +70,19 @@ Any gateway-device will contact the MQTT broker.
 
 ### Topics
 
-* The "/mesh/crypt/CHANNELID/NODEID/PORTID" [topic](https://www.hivemq.com/blog/mqtt-essentials-part-5-mqtt-topics-best-practices/) will be used for messages sent from/to a mesh.
+* The "/mesh/crypt/CHANNELID/NODEID" [topic](https://www.hivemq.com/blog/mqtt-essentials-part-5-mqtt-topics-best-practices/) will be used for (encrypted) messages sent from/to a mesh.
 
 Gateway nodes will foward any MeshPacket from a local mesh channel with uplink_enabled.  The packet (encapsulated in a ServiceEnvelope) will remain encrypted with the key for the specified channel.  
 
 For any channels in the gateway node with downlink_enabled, the gateway node will forward packets from MQTT to the local mesh.  It will do this by subscribing to mesh/crypt/CHANNELID/# and forwarding relevant packets.
 
-If the channelid 'well known'/public it could be decrypted by a web service (if the web service was provided with the associated channel key), in which case it will be decrypted by a web service and appear at "mesh/clear/CHANNELID/NODEID/PORTID". Note: This is not in the initial deliverable. 
+* If the channelid 'well known'/public it could be decrypted by a web service (if the web service was provided with the associated channel key), in which case it will be decrypted by a web service and appear at "mesh/clear/CHANNELID/NODEID/PORTID". Note: This is not in the initial deliverable. 
 
 FIXME, consider how text message global mirroring could scale (or not)
 FIXME, possibly don't global mirror text messages - instead rely on matrix/riot? 
 FIXME, consider possible attacks by griefers and how they can be prvented
 
-* The "/mstat/NODEID" topic contains a simple string showing connection status of nodes.  We rely on the MQTT feature for automatically publishing special failrue messages to this topic when the device disconnects.
+* The "/mesh/stat/NODEID" topic contains a simple string showing connection status of nodes.  We rely on the MQTT feature for automatically publishing special failrue messages to this topic when the device disconnects.
 
 #### Service Envelope