Suggestion for new Node Type --> CLIENT_PREFERRED

[Syridian]

I have a suggestion for a new node type that might help a little with routing. I have looked for similar threads, but happy to have any I have missed pointed out to me. There may be reasons this idea won't work, I'm happy to hear them. The details below are just a suggestion, and I'm happy to work with any developers out there to test code if they are willing to help make it happen.

CLIENT_PREFERRED
Client_Preferred nodes operate as standard Client nodes, however they also have a list of short names that they will immediately, (or shortly after) rebroadcast if they recieve a packet from a node on the list. So it's similar to adding rebroadcast LocalOnly but for a selected list of nodes, and it could also have a much shorter rebroadcast delay, though still delayed from ROUTER and REPEATER nodes.

Why? To provide a means of psudo-trunking without flooding the mesh with additional ROUTERs or REPEATERs so that there's a mid-tier trunking solution. It could also encourage people to create quicker trunks to minimise hops between locations whilst still allowing the mesh to work as normal. Users could set up nodes to provide themselves a prefered route between nodes to get packets into harder to reach areas.

Issues? Possibly could cause issues with current mesh setups with non-CLIENT_PREFERRED aware nodes rebroadcasting packets that might affect he dynamics of the current mesh. I'm starting this thread to have these discussions amongst a group of people who understand the mesh dynamics better than me. ;) Hoping people will reason through things rather than just shut the conversation down, or at least explain what I'm missing.

[Syridian]

Summary

This proposal introduces an optional enhancement to the existing Meshtastic node architecture via a new node role: CLIENT_PREFERRED.

The goal is to provide a low-overhead mechanism for improving packet delivery in targeted scenarios—such as between isolated mobile clients and fixed base nodes—without requiring full REPEATER or ROUTER functionality. This can help facilitate pseudo-trunking or semi-backbone behavior while maintaining mesh efficiency.

---

🔧 How It Works

• CLIENT_PREFERRED nodes behave exactly like standard CLIENT nodes except:

  • They rebroadcast only packets received directly (single-hop) from a small, static list of trusted node IDs (e.g., 5–10).

  • This list is user-defined (e.g., via config file, app setting, or CLI), and not dynamically updated.

  • No rebroadcasting of packets that were themselves relayed by intermediate nodes (to prevent loops or flooding).

---

✅ Benefits

• Lightweight and Backward-Compatible: CLIENT_PREFERRED nodes do not require any other node to be aware of the new role, ensuring seamless interoperability.

• Scoped Rebroadcasting: Strict control over who a node rebroadcasts for keeps traffic low and avoids the issues that arise from indiscriminate repeaters.

• Improves Delivery for Specific Links: Ideal for improving message reliability between clients with weak connections to the mesh backbone.

• Simplified Configuration: Users define a simple, comma-delimited list of trusted node IDs—no discovery or sync mechanisms needed.

---

⚠️ Considerations

Concern | Mitigation

Potential rebroadcast loops | Only rebroadcast packets received directly (not forwarded ones)

List misconfiguration | Cap the list size (e.g., 5-10 IDs), add UI/CLI validation

Security/trust | (Optional future enhancement) Support node ID validation or encrypted pairings

---

🧠 Use Cases

• A fixed node in a remote camp rebroadcasts for a handful of mobile trackers in that area.

• A semi-fixed boat node selectively rebroadcasts only for the shore station, improving marine reach without mesh pollution.

• A neighborhood node helps deliver packets for specific users who frequently transmit large data (e.g., GPS beacons or text) without creating general traffic noise.

---

🔄 Relationship to Existing Node Types

• Does not replace or modify any current node roles.

• CLIENT nodes remain unaffected and unaware of this role.

• Acts as a niche middle ground between CLIENT and REPEATER modes.

---