There can be several reasons why a direct message (DM) does not make it to a recipient. Let’s look at the two most common reasons.
First, you need to understand how DM are constructed. All messages on a MeshCore network are cryptographically signed using a public key encryption. What this really means is that each node on the network has a public key (that is the hexadecimal number that you see on the contacts in the MeshCore app). For example the Volusia ARES Room has a public key of d6cce274..... There is a lot more to that public key (it is 16 bytes/32 hexadecimal characters) but usually it is only referred to as the first 2-3 bytes (4-6 characters).
In addition, each node on the network has a private key which only the node knows. There is a way of extracting the private key out of a node but it is not normally needed except for a couple of special cases. So you will never know what the nodes private key is and it should never be extracted and sent anywhere. Once it is extracted it becomes pretty easy to forge messages and make it appear that they came from the original node. This makes public key encryption totally useless if the private keys become exposed and known.
The way that messages work is that Alice wants to send Bob a DM. Her Companion will take the message that she types and encrypt the message with Bob’s public key (which is known) and transmit the message. Bob’s Companion then receives the message and needs to decrypt the message. The message can only be decrypted with Bob’s private key (because it was encrypted with his public key). No other key will ever be able to decrypt the message. Now when Bob sends a response his Companion will do the reverse by taking the response and encrypt it with Alice’s public key. Which of course can only ever be decrypted with Alice’s private key. There you have it….MeshCore communication in a nutshell. This is how MeshCore provides secure communication across the network.
This is a bit of a long explanation, but I wanted to provide enough detail so that the mechanics underneath could be understood at a fundamental level. It simply comes down to both sides of communication need to have each other’s public key. If only one person has the other’s public key any messages sent are effectively ignored.
I simplified the above scenario just a bit by skipping over acknowledgements (ACKs). I stated that when Bob sent a reply to Alice’s message. Well the truth is that Bob’s Companion sends an automatic response upon receiving Alice’s message called an ACK. This is Bob’s Companion’s way of sending confirmation back to Alice’s Companion that the message has been received. If Bob’s Companion does not have Alice’s public key, then there is no way to send the ACK. Alice would typically see this problem as a message the fails to send.
The second common reason for DM not making it through the network is caused by a somewhat similar result to the above scenario. First, let’s start with the understanding that Alice and Bob do have each other’s public keys and there is some path through the network between Alice and Bob but it is not known ahead of time.
When Alice this time tries to send a message to Bob, Alice’s Companion will first send a flood routed packet. When Bob’s Companion receives the message, it now has a path through the network to Alice (the path gets recorded by each repeater adding it’s ID to the path section of the packet). In fact, Bob’s Companion may receive a couple copies of the same message only with different paths. The Companion being a relatively simple device just chooses the path from the first message it receives. Even if there is a better path that is received later the Companion has no way of knowing that it is a better path. When Bob’s Companion sends back its ACK it will now use the discovered path and Alice’s Companion will take note and record the path for future DMs.
Now there are several possibilities here that may happen on the network and they may occur at anytime. So you may be chatting with a friend through DMs when all of a sudden the connection breaks and messages don’t get through. So here are a couple of things that could be going on:
- Bob’s Companion never receives the message to begin with
- Alice’s Companion never receives Bob’s ACK
- Local interference close to one of the repeaters in the path causes a message/ACK not to be received
- Similarly, local interference may cause a repeater’s transmission to be corrupted
- One of the repeaters in the path is no longer functioning
So you can see that there are a bunch of reasons why a DM can fail going across the network. This is why the Companions will attempt to send the message 3 times through DM and when it fails to get an ACK on each of the 3 attempts, it will fallback to sending a flood message again in an attempt to learn if there is a new path through the network.
This does not mean that you are doing anything wrong when trying to send DMs; it could be just something fundamentally has changed on the network to cause the DMs to fail.
Now before you jump to the next methodical question (“Well then why do my messages in channels go through?”) you need to understand that channel messages are always flood routed messages. The simple way to understand the difference is to remember that there is only 1 DM message on the network at any given time. A flood message depends upon repeater density and how many repeaters can be seen at each repeating of the message, but there are multiple copies of the message on the network concurrently. On a really large mesh network with hundreds of repeaters, there very well could be 20-50 copies of the message on the network. Where the DM message is just one hop away from being lost, a flood message is like water and it will get through even if a few of the messages get lost.