Add receive-path to received contact message

[do6uk]

Would it be possible to add the received path to the payload or attributes of an received contact message?

The data should be present, because in RX_LOG the path is supplied.

Alternatively the there could be the packet hash in the attributes of the contact message event, so that I can use the data from RX_LOG.

[fdlamotte]

I would have done it if the path was in the packet received from the companion when syncing, but it is not.

The flow for receiving messages from the companion radio is the following

• companion receives message from LORA
• sends the complete packet (as any other) through BLE if connected as rx_log
• stores the message
• sends a notification to the node if connected

When the app wants it syncs message from the companion radio and receives that packet from the sync command (the app syncs until it gets all stored msgs):

RESP_CODE_CONTACT_MSG_RECV_V3 {
  code: byte,   // constant 16
  snr: byte,     // SNR*4
  reserved: bytes(2),   // zeroes
  pubkey_prefix: bytes(6),     // just first 6 bytes of sender's public key
  path_len: byte,     // 0xFF if was sent direct, otherwise hop count for flood-mode
  txt_type: byte,     // one of TXT_TYPE_*  (0 = plain)
  sender_timestamp: uint32,
  text: varchar    // remainder of frame  
}

We could store the path received in rx_log and correlate the packet but sadly in text msgs there is not much that is not encrypted, so we can't even "easily" know if the packet is for us (and then it would be good to know who sent it to store the information) ...

If you want to correlate, you'll have to use sender_timestamp and text, I think this is what we have that can identify the msg (the sender timestamp is set by the sender and should be unique, except for retries) but you have to go in the encrypted msg to do correlation

[fdlamotte]

I was not looking at the good place (letsme.sh doesn't seem to show unencrypted data in text msgs) so we have first byte of src and dst key

if connected this should be enough to correlate packet in most cases (as the recv_msg event should occur just after the rx_log)