Simplify Device Role

[karsey24]

Problem

Every single video, post, and article about getting started with MT includes a "DO NOT SELECT ROUTER" warning. As a new user myself, I find the "Device Role" configuration to be awful in every way. Specifically,

1. The names are not clear, and even the explanations are confusing. I still can't tell why I would prefer CLIENT_HIDDEN to CLIENT_MUTE!
2. The names of each role, and the implications of each role, have serious contradictions and are too limiting.

This leads to confusion for new users ("Why am I a client?" "My node is nice, why shouldn't I be a router?") and frustration for more experienced users. A sensor with a reliable power supply might make for a great client node, for example. Why are we mixing up the purpose of a node with its willingness or ability to participate in extending coverage?

Also, if there's ever a desire to add more intelligent routing options to MT, it would be nice to make this configuration data more informative. Permanent installs form great backbones, but short term beacons (perhaps left at the head of a trail before a hike) can also play a role.

Solution

Split the "Role" into its components: purpose, participation, and location. These are easier to explain to new users, and more helpful for the pros.

Proposed categories: Device Type, Device Location, and Device Participation

Device Types

Infrastructure	Device provides personal or public service for the mesh
Personal device	App connected or stand alone messaging device.
Tracker	Broadcasts GPS position packets as priority.
Lost&Found	Broadcasts location as message to default channel regularly to assist with device recovery.
Sensor	Broadcasts telemetry packets as priority.
Tak	Optimized for ATAK system communication.
Tak Tracker	Enables automatic TAK PLI broadcasts.

Device Locations

Fixed Permanent	Device can be reliably added for routing purposes
Fixed Short Term	Device can be reliably added for routing purposes, for now
Mobile	Device is unreliable

Device Participation levels

Full greedy	Node intends to rebroadcast every packet right away because it is extremely well-positioned
Full	Node intends to rebroadcast every packet at an optimal time
Base	Base station: always rebroadcasts packets from or to its favorited nodes. Rebroadcasts packets when no other node has done so.
Friendly	Node will rebroadcast packets when no other node has done so.
As-needed	Device that only broadcasts as needed for stealth or power savings.

Mapping current roles

CLIENT	Personal device; mobile; firendly
CLIENT_MUTE	Personal device; mobile; as-needed
CLIENT_HIDDEN	Personal device; mobile; as-needed
CLIENT_BASE	Personal device (or infrastructure); (any location); base
TRACKER	Tracker; mobile; as-needed
LOST_AND_FOUND	Lost&Found; mobile; as-needed
SENSOR	Sensor; (any location); as-needed
TAK	Tak; mobile; as-needed
TAK_TRACKER	Tak; mobile; as-needed
ROUTER	Infrastructure; fixed permanent; full greedy
ROUTER_LATE	Infrastructure; fixed permanent; full

This map of old types to new configurations would be super helpful during the switch. I was also careful about the names to help nudge users in the right direction: "Friendly" is good, "Greedy" is bad, and "Personal device" sounds better than "Client."

If we ever make it possible to specify routes, this would also really help because devices would prioritize sending via visible infrastructure instead of a ton of random mobile nodes. However, I am not proposing routing here. I am simply flagging a potential side benefit from this idea.

None of this proposal was suggested or generated by AI, btw. I just really want to see MT grow and improve, and I think it would be great to make this change.

[karsey24]

Thinking about it a bit more, the participation levels for "friendly" "base" and "full" are not very different. Adjusting those categories, or at least changing the word "full," might be a good idea.

[dirspb]

Fully agreed with the problem. Role names should be intuitive. I was thinking of ROUTER -> MASTER_ROUTER or BACKBONE_ROUTER or INVASIVE_ROUTER, CLIENT -> ROUTER, CLIENT_BASE -> PERSONAL_ROUTER, CLIENT_MUTE -> CLIENT. This suggestion is even better.
My 50 cent:

• to start from simplest question: fixed location or mobile? And then list only applicable roles.
• if fixed location is selected, there should be no way to broadcast the location more often then once per hour and use GPS or phone location.

[karsey24]

I absolutely envision this being presented as some sort of setup flow. We could even show users basic presets:

• Personal device (Personal/Mobile/Friendly)
• Base (Infrastructure/Fixed Permanent/Base)
• Sensor (Sensor/Fixed Permanent/As-needed)
• Tracker (Tracker/Mobile/As-needed)

And then have an "advanced setup" part as well. Users will still need to know what to choose, but it's much more obvious with these names and options. And it's better than the current system because there are no unintended drawbacks to picking an option.

I still prefer my overall setup, but "Invasive" is a good word to use here. What if "Full" from my table became "Repeater," and "greedy" became "Invasive"?

Fixed locations should still be able to use the "smart" broadcast setting, but maybe they're configured to check GPS less often or something. I don't know. I have less of a dog in that fight.