Platform

Cross-Platform

Description

Introduce a CLIENT_BASE_LATE role (or equivalent behavior change) where a base node treats favorited nodes with ROUTER_LATE semantics instead of ROUTER semantics, while behaving as a normal CLIENT for all other traffic.

Problem

In sparse meshes, the current CLIENT_BASE behavior can unintentionally reduce propagation for the very nodes it's meant to help:

• CLIENT_BASE currently acts like a ROUTER for favorites and CLIENT for others.
• When a favorited device sends a message:
  1. CLIENT_BASE rebroadcasts it early with router‑like priority.
  2. A critical intermediate CLIENT node (not favorited, but essential as a hop to the wider mesh) hears this rebroadcast.
  3. As a CLIENT, it cancels its own rebroadcast due to managed flooding (it has already "heard" the packet).
• Result: the important intermediate hop may never rebroadcast, and the message doesn't reach the wider mesh.
• In testing, this performed worse than using ROUTER_LATE on the base node.

Proposed Solution: CLIENT_BASE_LATE

Add a CLIENT_BASE_LATE role (or update CLIENT_BASE behavior) with:

• For favorited nodes: use ROUTER_LATE semantics
  • Always rebroadcast once for favorites
  • Do so late, after other roles, to avoid stealing hops or silencing other CLIENTs
• For non‑favorites: keep existing CLIENT behavior
  • Normal managed flooding, canceling rebroadcast if another node rebroadcasts first

Benefits

• Improves reliability for favorite devices in sparse or tricky RF topologies
• Reduces need to run "naughty" ROUTER_LATE on rooftop bases
• Avoids hop gobbling, since the base's rebroadcast comes late and primarily acts as a safety net instead of a primary router
• Preserves the "personal base station" concept of CLIENT_BASE while addressing real-world routing edge cases

Based on this reddit post which has more background information: https://www.reddit.com/r/meshtastic/comments/1pcn16v/should_client_base_treat_favorites_like_router/