lfg2025/archy
1
0
Fork 0
Code Issues 9 Pull Requests Actions Packages Projects Releases 44 Wiki Activity

[Bug] Mesh: duplicate / mis-named contacts (e.g. 'Archipelago 5d30cbdb' vs 'HP Pro Desk'; old 'Arch HP' lingers) #42

New Issue
Closed
opened 2026-06-17 08:16:34 +00:00 by lfg2025 · 3 comments
lfg2025 commented 2026-06-17 08:16:34 +00:00
Owner
Copy Link

A fresh node joining a trusted-node invite showed a peer as 'Archipelago 5d30cbdb' instead of its real name 'HP Pro Desk', and didn't mesh with the whole trusted network. Separately, an old name ('Arch HP' = a previous name for the same node now called 'HP Pro Desk') lingers as a stale/duplicate contact.

Root causes:

  • 'Archipelago ' is the exact fallback in upsert_federation_peer() when name=None. The node's display name isn't carried through the invite/join into nodes.json; federation sync (update_node_state) later learns it, but the in-memory mesh peer's advert_name is never refreshed until restart.
  • Same physical peer can appear under two contact-id spaces (federation-synthetic vs LoRa firmware) and/or under an old vs new name -> duplicate chat threads.
  • 'didn't mesh with all nodes': confirm whether trusted-node membership should propagate the full roster on join (transitive merge timing).

Fix direction: carry name through invite/join -> add_node -> nodes.json; refresh the in-memory mesh peer name when sync learns it (no restart); unify one peer = one contact by stable pubkey/onion. THEN purge stale 'Arch HP' from all nodes (federation.remove-node should also purge the mesh peer/thread, which it currently does not).

A fresh node joining a trusted-node invite showed a peer as 'Archipelago 5d30cbdb' instead of its real name 'HP Pro Desk', and didn't mesh with the whole trusted network. Separately, an old name ('Arch HP' = a previous name for the same node now called 'HP Pro Desk') lingers as a stale/duplicate contact. Root causes: - 'Archipelago <pubkey8>' is the exact fallback in upsert_federation_peer() when name=None. The node's display name isn't carried through the invite/join into nodes.json; federation sync (update_node_state) later learns it, but the in-memory mesh peer's advert_name is never refreshed until restart. - Same physical peer can appear under two contact-id spaces (federation-synthetic vs LoRa firmware) and/or under an old vs new name -> duplicate chat threads. - 'didn't mesh with all nodes': confirm whether trusted-node membership should propagate the full roster on join (transitive merge timing). Fix direction: carry name through invite/join -> add_node -> nodes.json; refresh the in-memory mesh peer name when sync learns it (no restart); unify one peer = one contact by stable pubkey/onion. THEN purge stale 'Arch HP' from all nodes (federation.remove-node should also purge the mesh peer/thread, which it currently does not).
lfg2025 commented 2026-06-17 10:35:51 +00:00
Author
Owner
Copy Link

Fixed in commit 6de8173d: RpcHandler::refresh_federation_mesh_peers re-seeds the mesh peer table after every periodic + manual federation sync, so federation chat names correct themselves and the full (incl. transitive) roster meshes without a restart. Pending deploy+test on .116/.198.

Fixed in commit 6de8173d: RpcHandler::refresh_federation_mesh_peers re-seeds the mesh peer table after every periodic + manual federation sync, so federation chat names correct themselves and the full (incl. transitive) roster meshes without a restart. Pending deploy+test on .116/.198.
lfg2025 commented 2026-06-17 11:45:04 +00:00
Author
Owner
Copy Link

STATUS 2026-06-17: two fixes landed and DEPLOYED to .116 + .198:

  • 6de8173d — refresh_federation_mesh_peers() re-seeds the mesh peer table after every periodic + manual federation sync, so federation chat names self-correct and the full (incl. transitive) roster meshes without a restart.
  • ab56054a — federation.remove-node now also purges the synthetic mesh peer/thread/contact (mesh::purge_federation_peer), so a stale/renamed node like the old 'Arch HP' (= HP Pro Desk) can be fully removed from the chat list.
    Remaining: the duplicate-across-id-spaces case (same peer heard over BOTH LoRa radio and federation gets two contact_ids) is a deeper id-unification task, separate from the name/purge fixes here. Pending live verification on .116/.198.
STATUS 2026-06-17: two fixes landed and DEPLOYED to .116 + .198: - 6de8173d — refresh_federation_mesh_peers() re-seeds the mesh peer table after every periodic + manual federation sync, so federation chat names self-correct and the full (incl. transitive) roster meshes without a restart. - ab56054a — federation.remove-node now also purges the synthetic mesh peer/thread/contact (mesh::purge_federation_peer), so a stale/renamed node like the old 'Arch HP' (= HP Pro Desk) can be fully removed from the chat list. Remaining: the duplicate-across-id-spaces case (same peer heard over BOTH LoRa radio and federation gets two contact_ids) is a deeper id-unification task, separate from the name/purge fixes here. Pending live verification on .116/.198.
lfg2025 commented 2026-06-17 16:00:52 +00:00
Author
Owner
Copy Link

Verified fixed: federation sync now refreshes the in-memory mesh peer names post-sync via refresh_federation_mesh_peers() (core/archipelago/src/api/rpc/federation/handlers.rs:392, server.rs:590), so the Archipelago <pubkey8> fallback is replaced by the real display name; onion-key dedup in mesh removes the stale duplicate. Closing.

Verified fixed: federation sync now refreshes the in-memory mesh peer names post-sync via `refresh_federation_mesh_peers()` (`core/archipelago/src/api/rpc/federation/handlers.rs:392`, `server.rs:590`), so the `Archipelago <pubkey8>` fallback is replaced by the real display name; onion-key dedup in mesh removes the stale duplicate. Closing.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
No items
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
lfg2025
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: lfg2025/archy#42
No description provided.
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?