TBEAM, HELTEC, etc... Starting in 1.2.11 moved to hw_model enum in the NodeInfo object. Apps will still need the string here for older builds (so OTA update can find the right image), but if the enum is available it will be used instead.
A globally unique ID string for this user. In the case of Signal that would mean +16504442323, for the default macaddr derived id it would be !<8 hexidecimal bytes>. Note: app developers are encouraged to also use the following standard node IDs "^all" (for broadcast), "^local" (for the locally connected node)
In some regions Ham radio operators have different bandwidth limitations than others. If this user is a licensed operator, set this flag. Also, "long_name" should be their licence number.
A full name for this user, i.e. "Kevin Hester"
Deprecated in Meshtastic 2.1.x This is the addr of the radio. Not populated by the phone, but added by the esp32 when broadcasting
The public key of the user's device. This is sent out to other nodes on the mesh to allow them to compute a shared secret key.
Indicates that the user's role in the mesh
A VERY short name, ideally two characters. Suitable for a tiny OLED screen
Broadcast when a newly powered mesh node wants to find a node num it can use Sent from the phone over bluetooth to set the user id for the owner of this node. Also sent from nodes to each other when a new node signs on (so all clients can have this info) The algorithm is as follows: when a node starts up, it broadcasts their user and the normal flow is for all other nodes to reply with their User as well (so the new node can build its nodedb) If a node ever receives a User (not just the first broadcast) message where the sender node number equals our node number, that indicates a collision has occurred and the following steps should happen: If the receiving node (that was already in the mesh)'s macaddr is LOWER than the new User who just tried to sign in: it gets to keep its nodenum. We send a broadcast message of OUR User (we use a broadcast so that the other node can receive our message, considering we have the same id - it also serves to let observers correct their nodedb) - this case is rare so it should be okay. If any node receives a User where the macaddr is GTE than their local macaddr, they have been vetoed and should pick a new random nodenum (filtering against whatever it knows about the nodedb) and rebroadcast their User. A few nodenums are reserved and will never be requested: 0xff - broadcast 0 through 3 - for future use