[Feature Request]: (relies on message replay) Clients that get repeated requests for replay can promote themselves

[NomDeTom]

Platform

Cross-Platform

Description

Once the replay function is introduced, nodes will advertise hashes of packets they hear/hold in their messageDB. Other nodes will be able to request replay of a packet to fill gaps in transmission.

If a replaying client node is repeatedly requested to replay packets, it may safely assume that it is fulfilling a routing function for another node, regardless of other considerations.

The replaying client node may want to promote itself to a "mandatory broadcast" role (e.g. router, router_late) either within the normal contention window or the late contention window. This will save airtime from packet hash adverts and the repeated requests for replay.

This promotion would be temporary, with some kind of time-out built in, based on the number of replay requests it receives. The time-out would allow for shifting RF conditions, node positions, mesh density, etc.

The renewal could be based on low-airtime measures like the identity of the requesting node's signal strength or a simple resetting of the timer based on replay requests.

[NomDeTom]

This is related to #8049

[Ryu945]

1. This would be a very good idea but it should only promote itself to guarantee rebroadcast. It should stay in the Client Window. You can seriously mess up routing by allowing it to change windows. There is a reason this node isn't a router already after all.

2. It should take note of which router did the broadcasting for the message it is being asked to rebroadcast. If node C hears messages from Node A and Node B. Node D is always asking for a rebroadcast but only for Node A messages then Node C will temporarily promote itself to guarantee rebroadcast for Node A messages only. It will not do this promotion for Node B since Node D never asked for a replay of any of Node B messages.