I believe that when one launches meshtastic --sendtext "message" --dest [UID], the device looks at its nodelist, finds the public key of the destination node and uses it to construct the packet.
If the recipient node is not in the sending device's nodelist, the following error is generated: "PKI_SEND_FAIL_PUBLIC_KEY" The only way to get this far is that a command argument --dest included an integer or hexadecimal UID value. The user constructing the message then, ostensibly, knows the recipient's UID. He or she should also know the recipient's public key.
When would this condition occur? Never with the Android or web application, because the recipient node must be in the sender's nodelist in order to launch a message dialog box. It can only occur wihen a CLI user constructs his or her own message to a node not in the nodelist. This might happen when the when the sending device has recently been flashed, its nodedb has been reset, or the node removed.
If the recipient node is not regularly broadcasting its existence, there is no way the sender's nodelist will update with the recipient's public key. In an emergency, the sender would have to wait, on average, half of the time in position.broadcast_secs (default is 15 minutes), or could wait forever.
My request is to add --pki base64:[DESTINATION_PUBLIC_KEY] to use when the sender's nodelist is incomplete. The command line DESTINATION_PUBLIC_KEY would take the place of any key or blank found in the nodelist.
This option is no more likely to be added to the bag of stupid user tricks than any other message to an invalid UID. In the case that a message or admin command is sent to a valid UID but with an invalid PKI, there is already a response: ADMIN_PUBLIC_KEY_UNAUTHORIZED.
As to the name of the argument, --pki seems as good as any to me, but --dpk for Destination Public Key is okay, or whatever the developer likes best.
I believe that when one launches meshtastic --sendtext "message" --dest [UID], the device looks at its nodelist, finds the public key of the destination node and uses it to construct the packet.
If the recipient node is not in the sending device's nodelist, the following error is generated: "PKI_SEND_FAIL_PUBLIC_KEY" The only way to get this far is that a command argument --dest included an integer or hexadecimal UID value. The user constructing the message then, ostensibly, knows the recipient's UID. He or she should also know the recipient's public key.
When would this condition occur? Never with the Android or web application, because the recipient node must be in the sender's nodelist in order to launch a message dialog box. It can only occur wihen a CLI user constructs his or her own message to a node not in the nodelist. This might happen when the when the sending device has recently been flashed, its nodedb has been reset, or the node removed.
If the recipient node is not regularly broadcasting its existence, there is no way the sender's nodelist will update with the recipient's public key. In an emergency, the sender would have to wait, on average, half of the time in position.broadcast_secs (default is 15 minutes), or could wait forever.
My request is to add --pki base64:[DESTINATION_PUBLIC_KEY] to use when the sender's nodelist is incomplete. The command line DESTINATION_PUBLIC_KEY would take the place of any key or blank found in the nodelist.
This option is no more likely to be added to the bag of stupid user tricks than any other message to an invalid UID. In the case that a message or admin command is sent to a valid UID but with an invalid PKI, there is already a response: ADMIN_PUBLIC_KEY_UNAUTHORIZED.
As to the name of the argument, --pki seems as good as any to me, but --dpk for Destination Public Key is okay, or whatever the developer likes best.