[Feature Request]: DM the Owner - Contact Info (NodeID) for mandatory-rebroadcast roles

[korbinianbauer]

Platform

Cross-Platform

Description

Tl;dr: ROUTERs and Co. should offer to DM the owner.

---

Mandatory-rebroadcast roles, especially ROUTER, but also ROUTER_LATE and CLIENT_BASE can cause trouble for other users. (E.g. #8367)

Usually, these nodes are not connected to a phone, so you cannot easily reach the owner/maintainer by DM. Trying to reach them via public channels or other platforms (Reddit, Telegram, HAM clubs) is hit and miss at best. Not everyone reads or uses these.

However, these roles are often connected to another of the owner's personal nodes anyway for remote administration.

This feature request is about:

1. As a mandatory-rebroadcast node, remember the NodeID of the node last used for remote administration.
2. This information should then be used in one of two ways:
   Option A: Allow DMs to be sent to mandatory-rebroadcast roles. These DMs would be automatically forwarded to the last-used remote administration node.
   Option B: Have infrastructure nodes (Routers, etc.) broadcast the NodeID of their last-used remote administration node as part of their NodeInfo. The client app could then offer a button to DM that NodeID directly.

Synergic proposals:

• If [Feature Request]: Make mandatory-rebroadcast roles only possible to enable via remote admin #8347 is implemented, every mandatory-broadcast role has to have a remote-admin key, with this feature it would also automatically have a contact node configured.

• If [Feature Request]: Apply an expiry time on router roles, so that they fall-back to router_late if not actively maintained. #8378 is implemented and falls back to Client if not maintained, the contact nodeID would even be guaranteed to be up-to-date

Limitations

• Option B) requires being able to DM the owner's node directly, which requires its public key, which requires having heard a NodeInfo packet from it before.
• Only works if the infrastructure node is using the default primary channel.
• Contact node has to be online and reachable to receive the DM
  -> this feature will not guarantee you can reach the owner, just provide an on-platform, default way to do it, and increase your chances of success.

Security concerns:

• Afaik None, "registering" a new NodeID as contact info requires the remote admin node's private key, same barrier as all remote adminstration actions.

Privacy concerns:
IMO none, here's why:

Without this feature:
ADMIN_APP packets are sent via the primary channel, which is the decryptable-by-everyone public channel by default. Example: https://malla.meshtastic.es/packet/16186810

The from and to fields specifically however are alway unencrypted. The payload (specific settings) is encrypted with the channel's PSK.

Therefore, the NodeID used to remotely administer another node is already public information, no matter what.

Currently, this information is only revealed when the maintainer performs a remote administration action.

If an infrastructure owner wishes to keep the specific settings private, they currently have to use a custom primary channel for remote administration, but the from and to fields stay unencrypted.

With this feature:
This feature would make the administrator's NodeID more readily available—which is the intended purpose—but it does not expose any new, previously protected information.

Bandwidth concerns:

• Option A) None
• Option B) NodeInfo packets of those roles would increase by the size of a NodeID, which is 4 bytes afaik

[Talie5in]

Option A) I have a specific node that is not my day to day node, that I use for remote admin of my infrastructure nodes, it's not online all the time, only when I need to use it to either make changes or while I am deploying a new infrastructure node to confirm remote admin is working etc - so you would be messaging thin air (or it would be forwarding a DM to thin air)

Option B) This is not going to work for a variety of reasons - one being you are taking a choice away from infrastructure node owners, they may not want others to know which infrastructure node's belong to them.

As an "optional" entry - yes, not as a forced requirement.

[korbinianbauer]

I have a specific node that is not my day to day node, that I use for remote admin of my infrastructure nodes, it's not online all the time

Fair point. I'd argue though that this limitation correlates with responsible infrastructure owners that even think about having an extra, designated node for that.

Those that carelessly set one of their nodes to Router to put it on the balcony are more likely to use a personal everyday node for administration.

I've expanded my comment on this concern in the "Limitations" section above.

... node owners, they may not want others to know which infrastructure node's belong to them.

I've expanded my comment on this concern in the "Privacy concerns" section above. Tl;dr: If this is a concern, it already is an issue right now, and the current countermeasure stays as effective as it is now.

As an "optional" entry - yes, not as a forced requirement.

That way we're not gonna hit the target audience unfortunately... careless node operators will likely also not bother to use this feature if it's an optional, manual step.

Thanks for your input.

[Talie5in]

I've expanded my comment on this concern in the "Privacy concerns" section above.

Valid point, but as you also point out, those running a custom primary channel, the to/from is not seen and is therefor private, some of this may also be a hangover where they only want telemetry to be visible to themselves (where telemetry goes over the primary (or was the case, unsure if that's changed recently)

Which breaks down this further, those running infrastructure nodes, where the primary channel is not a "default/public" one, and do not have a "default/public" secondary channel - but are a router/router_late with rebroadcast set to "all", again, no one is going to see this new "infrastructure owner" flag - just a unnamed node in their trace/path/nodelist.

[korbinianbauer]

those running a custom primary channel, the to/from is not seen and is therefor private

Yes, which would stay this way, since the NodeInfo is sent over that private channel, too.

no one is going to see this new "infrastructure owner" flag - just a unnamed node in their trace/path/nodelist.

Yes, same as now, right?

I don't see any privacy issues here. What was private remains private, what wasn't private becomes easier to access.