Implementation Details for Relay Node Message display

[RCGV1]

Basic concept

All packets that are relayed from a 2.6+ node will include a relay_node field in the header containing the last byte of the relaying node's id. Using this we can determine who relayed a message that we received.

Implementation

When we receive a message we store the relay_node of the packet in our database. When a user checks the details of a recieved message we search our app node databse for which nodeid matches with the relay_node if there are multiple results we sort by which has the least hopsAway.

let relaySuffix = Int64(self.relayNode & 0xFF)
let request: NSFetchRequest<UserEntity> = UserEntity.fetchRequest()
request.predicate = NSPredicate(format: "(num & 0xFF) == %lld", relaySuffix)

We then display the long name of the node that most likely relayed it.

For sent messages

We do a similar thing of storing how a ack got back to us to display who relayed a ack back to us in a dm. If you check the details of a acknowledged dm you will see the name of the node who got the ack back to you.

We also show how many nodes we heard reboradcasting our sent message. This is accomplished by keeping a count of relayNumbers and appending to it when we get an implicit ack packet.

(This has not been added yet to iOS but is planned) We also display a list of all nodes that we heard rebroadcast our message. This is because in a big mesh you can hear multiple nodes rebroadcasting your message and it is good to see who it is.

Reference the iOS PR:

meshtastic/Meshtastic-Apple#1486

[NomDeTom]

Adding to my comment on meshtastic/Meshtastic-Android#3656 the relaying node suggestion needs to be more than just the lowest hop count. In the screenshot I provided, that node hadn't been seen in 77 days, and was shown as the relaying node for a DM sent directly to it (even though it was out of range).

[ldti]

Something similar here.
The TAMI node is a MQTT node with no LORA nodes near it, so it will of course say "max retransmit reached."
HOWEVER, it is not the only node that retransmitted the message, as confirmed by others in the screenshot.

[1nv]

Please remove this:

1. This doesn't work correctly, as nodes are guessed by their lowest byte, and this guess might be incorrect on larger networks.
2. This message is shown for failed transmissions, which confuses users that the node (which is a random node with id ending with 00) is a culprit.

[teran1983]

I confirm. We have node 0500 in our network.
And the entire network receives this message.
The message disappears if you remove the 0500 entry from the node list.
But this only helps until node 0500 sends its contact information again.

[DirectX]

I confirm. We have node 0500 in our network. And the entire network receives this message. The message disappears if you remove the 0500 entry from the node list. But this only helps until node 0500 sends its contact information again.

Exactly the same. Node 0500 crashed all environment by confirming the relay of messages. This was nightmare before customized firmware for this node was applied which scrambles the initialization to not get 00 at the end.

[timurey]

We have nodes with IDs xxxx7e00 and xxxx5200. It looks like they broke the DM. Perhaps the firmware should change the ID if it ends in 00?