Problem Statement

When using my CLIENT or CLIENT_MUTE pocket node with my home CLIENT_BASE, the pocket node only sees the ACK from CLIENT_BASE. When the CLIENT_BASE has marginal mesh access (range/EMI/etc), the pocket node users are unable to determine whether or not the CLIENT_BASE was able to transmit to a next hop.

I believe it will be common for CLIENT_BASE to be used where pocket nodes already have poor signal. They will typically not be carefully designed infrastructure installations (e.g. unlike many ROUTER nodes which have very carefully designed installations). Therefore, this is likely to be a common issue.

My Context / Background

I'm not an expert at the physical-layer of Meshtastic. I'm going to suggest an idea to start the discussion, but it may be terrible. I'm open to other suggestions to solve the problem statement.

Proposed Solution

Add a "next hop" acknowledgement for favorited nodes using a CLIENT_BASE.

Idea for discussion

When CLIENT_BASE receives a message from a favorited node, it retransmits in the early time slot like normal.

When the CLIENT_BASE receives their retransmission ACK (i.e. sees someone else re-broadcast the pocket node's message), the CLIENT_BASE will send a new message to the originating pocket node. The new message will have 0 hops, a packet header destination of the pocket node's NodeID. This is essentially a direct message. This could optionally be !WantAck to save airtime.

The pocket nodes can be configured to permit this behavior from the CLIENT_BASE by favoriting the CLIENT_BASE. The pocket node will know to expect the "DM ACK" because the normal retransmission ACK (from the CLIENT_BASE's early retransmission) will have the CLIENT_BASE LSByte in the relay_node field and the retransmission will be in the early slot (eliminates collisions with normal CLIENT role LSBytes doing retransmissions).

If the expected DM ACK is not received, the pocket node can confirm this is not a 1-byte node ID collision by DM'ing all favorited CLIENT_BASE(s) with matching LSByte node ID (0 hops w/ WantAck).