Yeah, but I’m not sure you want to trust the user with this setting – RF conditions may change, the antenna may fall off, etc. Or a hiker may randomly perch on a splendid vista and have better coverage than any repeater. Actual nodes-in-view coverage may have nothing to do with a user-input setting.
IMHO, available battery power would be a better determining factor. We’d assume repeater nodes have plenty of power and can thus always run in “who cares about the watts” no-sleep mode, but we don’t want to drain a hiker’s last 10%. On the other hand, if that hiker’s node is plugged into a solar panel at camp, it’s an ideal router/repeater again.
(Side note, this is how the Prius uses battery power. When the traction battery is in the middle of its state-of-charge range, the car will blend battery power with engine power. But if the battery is above 90%, say after a long downhill where regenerative braking filled it to the brim, the car will prefer electric-only propulsion, until such time as the battery returns to normal range. Thus, prior to the release of an official PHEV version, there was an aftermarket plugin conversion kit which threw a bunch more batteries in the trunk and used a DC-DC converter to dump power into the traction battery, keeping it right at its 99% voltage, which persuaded the powertrain to run electric-only a lot of the time, until such time as the extra batteries were depleted, and the system reverted to its normal blended strategy. You’d go home, plug the extra batteries into the wall, and charge for tomorrow’s drive.
I mention this because it’s exactly how I picture Meshtastic working. A node automatically acts in “spend all the power!” mode when its battery is fully charged, because it has some external source, which might actually be a larger USB pack or something. When that goes away, it reverts to normal operation to make the most of the power that remains.)
EDIT: I think there’s a two-birds-with-one-stone approach: The user config bit should be “Act as repeater above this battery level”. So if you want the node to always act as a repeater, set that low and it’ll always be above it. If you want to never act as a repeater, set the threshold as 101%.
I think this is a good idea going forward anyway, for reasons mentioned in this Reddit thread. If two nodes (be they phones, or hardware nodes) can see each other directly over bluetooth, send the message that way! It’ll only occupy a few ms of the plentiful 2.4GHz spectrum, instead of spending many seconds stomping on the scarce sub-GHz spectrum.
It would be nice to be able to disable this for testers who want to make sure their messages go via Lora even if their testing phones are inches apart on the same bench, though…