make protobufs more real

TODO.md

@@ -1,6 +1,7 @@
 
-
 # High priority
+
+* watch for ntofies of numread changing
 * implement android side of mesh radio bluetooth link
 * investigate the Signal SMS message flow path, see if I could just make Mesh a third peer to signal & sms?
 * make signal work when there is no internet up
@@ -9,12 +10,14 @@
   public static final int PREKEY_TYPE                 = 3;
   public static final int SENDERKEY_TYPE              = 4;
   public static final int SENDERKEY_DISTRIBUTION_TYPE = 5;"
+* don't do mesh based algoritm for node id assignment (initially) - instead just store in flash - possibly even in the initial alpha release do this hack
+* use the lora net code on my current protoboard
+* investigate a 16 bit node number.  If possible it would make collisions super rare.  Much easier to just pick a nodenum and go.
+* add large packet reassembly?
 * optionally turn off crypto in signal
-* clean up sw update code in device side
-
 * change signal package ID
-* make compose based access show mesh state
-* add real messaging code/protobufs
+* good tips on which bands might be more free https://github.com/TheThingsNetwork/ttn/issues/119
+* make my android app show mesh state
 * use https://codelabs.developers.google.com/codelabs/jetpack-compose-basics/#4 to show service state
 * connect to bluetooth device automatically using minimum power
 * fix BT device scanning 
@@ -71,3 +74,5 @@ Don't leave device discoverable.  Don't let unpaired users do things with device
 
 * DONE have signal declare receivers: https://developer.android.com/guide/components/broadcasts#manifest-declared-receivers
 * fix // FIXME hack for now -  throw IdNotFoundException(id) in MeshService
+* clean up sw update code in device side
+* add real messaging code/protobufs

app/src/main/proto/mesh.options

@@ -0,0 +1,21 @@
+# options for nanopb
+# https://jpa.kapsi.fi/nanopb/docs/reference.html#proto-file-options
+
+*macaddr max_size:6 # macaddrs
+*id max_size:16 # node id strings
+
+*User.long_name max_size:40
+*User.short_name max_size:4
+
+# FIXME pick a higher number someday? or do dynamic alloc in nanopb?
+*DeviceState.node_db max_count:32
+*DeviceState.receive_queue max_count:32
+
+# FIXME, something more like 200? And do fragmentation and reassembly (for larger payloads) at the Android layer, not the esp32 layer.
+*Data.payload max_size:100
+
+*MeshPayload.subPackets max_count:4
+
+
+# MyMessage.name         max_size:40 
+# or fixed_length or fixed_count, or max_count

app/src/main/proto/mesh.proto

@@ -81,16 +81,22 @@ message User {
     string id = 1; // a globally unique ID string for this user.  In the case of Signal that would mean +16504442323
     string long_name = 2; // A full name for this user, i.e. "Kevin Hester"
     string short_name = 3; // A VERY short name, ideally two characters.  Suitable for a tiny OLED screen
+    string macaddr = 4; // This is the addr of the radio.  Not populated by the phone, but added by the esp32 when broadcasting
 }
 
 // Broadcast when a newly powered mesh node wants to find a node num it can use (see document for more
 // details)
+// FIXME in the initial proof of concept we just skip the entire want/deny flow and just hand pick node numbers at first.
 message WantNodeNum {
-    // No payload, just its existence is sufficient (desired node num will be in the from field)
+    uint32 desired_nodenum = 1; // The node number we want (note: these WantNodeNum packets are sent from a few special 'unassigned' nodenumbers)
+    string macaddr = 2; // the unique ID of my node, so that others can descriminate between anyone else who is also accidentially using the same unassigned node number
 }
 
 // Sent to a node which has requested a nodenum when it is told it can't have it
+// FIXME, should denials be sent as a broadcast also?
+// FIXME, how do we handle someone missing the denial and assuming it has the nodenum?
 message DenyNodeNum {
+    string macaddr = 1; // the macaddr of the node we are sending this denial to (so that the recipient can be sure the packet really as desined to them)
 }
 
 // A single packet might have a series of SubPacket included
@@ -160,6 +166,20 @@ message NodeInfo {
     Time last_seen = 5;
 }
 
+// This message is never sent over the wire, but it is used for serializing DB state to flash in the device code
+// FIXME, since we write this each time we enter deep sleep (and have infinite flash) it would be better to use some sort of append only data
+// structure for the receive queue and use the preferences store for the other stuff
+message DeviceState {
+    RadioConfig radio = 1;
+    repeated NodeInfo node_db = 2;
+
+    /// Received packets saved for delivery to the phone 
+    repeated MeshPacket receive_queue = 3;
+
+    /// Tells the phone what our node number is, can be -1 if we've not yet joined a mesh.
+    sint32 my_node_num = 4;
+}
+
 // packets from the radio to the phone will appear on the fromRadio characteristic.  It will support
 // READ and NOTIFY.  When a new packet arrives the device will notify?  possibly identify instead?
 // it will sit in that descriptor until consumed by the phone, at which point the next item in the FIFO