Support stable infrastructure identity across node-ID changes #233

New Issue

2026-10-27T09:24:15+01:00

adam commented

2026-10-27 09:24:15 +01:00

Summary

Please provide a supported way for operators and downstream monitoring tools to recognise continuity of infrastructure identity when a node ID changes but the node retains its cryptographic key.

PotatoMesh already stores observed node public keys, but its node read API does not expose them or provide an alternative stable identity reference. Consequently, consumers that track infrastructure by node ID cannot associate a replacement node with its established record.

Use case

A fixed Meshtastic infrastructure node is replaced or reconfigured. Its node ID changes, but its existing keypair is retained.

For example:

An established router has node ID !12345678.
After replacement, it appears as !87654321.
Both records have the same observed public key.
A downstream infrastructure-status page continues tracking the old ID and reports it as not recently heard, while the replacement appears as an unrelated node.

Matching names is not a reliable solution: names are editable, non-unique and readily copied. Manually updating every downstream consumer also loses the opportunity to preserve continuity across replacements.

This is particularly useful for long-lived infrastructure monitoring, where the logical installation should remain recognisable independently of its current hardware-derived node ID.

Existing behaviour and privacy considerations

I understand that excluding keys from the public read API is deliberate. PR #893 describes storing identity information without serving it, and the current tests enforce exclusion of public keys and destination hashes. Although I do think this hiding of public keys is misguided.

This request is therefore not to expose all stored keys unconditionally or to bypass existing privacy controls. It is to establish a supported mechanism for this operational use case while respecting that boundary.

Possible approaches

Would maintainers consider one of the following?

An authenticated, operator-only lookup that can correlate node records using their observed keys.
An explicit, default-off deployment option for exposing the relevant observed identity field.
Another operator-controlled stable identity reference or association mechanism that avoids publishing raw keys.
(my preference) exposing public keys.

These are suggestions rather than a prescribed implementation. A public fingerprint alone would still enable correlation, so it should not be treated as automatically resolving the privacy concern.

Any solution should preserve existing node opt-out, visibility and retention rules, and leave unrelated identifiers excluded.

Identity and safety limitations

Matching observed keys would provide continuity evidence, not proof of ownership or possession of the private key. Meshtastic NodeInfo broadcasts are not an authenticated ownership assertion.

A useful contract should distinguish:

No key observed.
A matching key observed under another node ID.
Multiple node IDs advertising the same key.
A changed key under an existing node ID.

It should not silently merge records or assume that identical advertised keys prove two records represent the same physical device. Downstream tools should be able to flag a replacement candidate for operator confirmation.

Desired outcome

An authorised operator or downstream monitoring tool can identify that a newly observed node is a continuation candidate for an established infrastructure identity, without relying on its name or current node ID.

Is there an existing supported mechanism for this? If not, which approach would fit PotatoMesh’s privacy and API design? I would be happy to contribute an implementation and regression tests once the intended contract is agreed.

## Summary Please provide a supported way for operators and downstream monitoring tools to recognise continuity of infrastructure identity when a node ID changes but the node retains its cryptographic key. PotatoMesh already stores observed node public keys, but its node read API does not expose them or provide an alternative stable identity reference. Consequently, consumers that track infrastructure by node ID cannot associate a replacement node with its established record. ## Use case A fixed Meshtastic infrastructure node is replaced or reconfigured. Its node ID changes, but its existing keypair is retained. For example: - An established router has node ID `!12345678`. - After replacement, it appears as `!87654321`. - Both records have the same observed public key. - A downstream infrastructure-status page continues tracking the old ID and reports it as not recently heard, while the replacement appears as an unrelated node. Matching names is not a reliable solution: names are editable, non-unique and readily copied. Manually updating every downstream consumer also loses the opportunity to preserve continuity across replacements. This is particularly useful for long-lived infrastructure monitoring, where the logical installation should remain recognisable independently of its current hardware-derived node ID. ## Existing behaviour and privacy considerations I understand that excluding keys from the public read API is deliberate. [PR #893](https://github.com/l5yth/potato-mesh/pull/893) describes storing identity information without serving it, and the current tests enforce exclusion of public keys and destination hashes. Although I do think this hiding of public keys is misguided. This request is therefore **not to expose all stored keys unconditionally** or to bypass existing privacy controls. It is to establish a supported mechanism for this operational use case while respecting that boundary. ## Possible approaches Would maintainers consider one of the following? - An authenticated, operator-only lookup that can correlate node records using their observed keys. - An explicit, default-off deployment option for exposing the relevant observed identity field. - Another operator-controlled stable identity reference or association mechanism that avoids publishing raw keys. - (my preference) exposing public keys. These are suggestions rather than a prescribed implementation. A public fingerprint alone would still enable correlation, so it should not be treated as automatically resolving the privacy concern. Any solution should preserve existing node opt-out, visibility and retention rules, and leave unrelated identifiers excluded. ## Identity and safety limitations Matching observed keys would provide **continuity evidence**, not proof of ownership or possession of the private key. Meshtastic NodeInfo broadcasts are not an authenticated ownership assertion. A useful contract should distinguish: - No key observed. - A matching key observed under another node ID. - Multiple node IDs advertising the same key. - A changed key under an existing node ID. It should not silently merge records or assume that identical advertised keys prove two records represent the same physical device. Downstream tools should be able to flag a replacement candidate for operator confirmation. ## Desired outcome An authorised operator or downstream monitoring tool can identify that a newly observed node is a continuation candidate for an established infrastructure identity, without relying on its name or current node ID. Is there an existing supported mechanism for this? If not, which approach would fit PotatoMesh’s privacy and API design? I would be happy to contribute an implementation and regression tests once the intended contract is agreed.

adam closed this issue

2026-10-27 09:24:15 +01:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: adam/potato-mesh#233