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

[Bug] Node Npub differs between Settings and Web5 > Identities > Node (must be the derived npub) #49

New Issue
Closed
opened 2026-06-17 09:38:56 +00:00 by lfg2025 · 3 comments
lfg2025 commented 2026-06-17 09:38:56 +00:00
Owner
Copy Link

Repro (.70, fresh ISO install of v1.7.98-alpha): the Node Npub shown in Settings does NOT match the npub in Web5 > Identities > Node.

  • Settings: npub1gsu3kamk257yfraspszczvtc64c92z2a7wzu9n5va34segm2yt4qguzjnc
  • Web5 > Identities > Node: npub13n7h5n6vmqre8shxvspt2uc4dn56pcv5vsc0ajx5ht2xzypnz6vqtvv3gt

Required: both must show the same, DERIVED npub (derived from the node seed/identity key). Determine which surface is wrong and make both read the single derived value.

Investigate: where Settings sources its Node Npub vs where Web5 Identities sources the Node identity; ensure one canonical seed-derived key feeds both. Likely two independent derivations (or one cached/stale) - converge on the seed-derived npub.

Repro (.70, fresh ISO install of v1.7.98-alpha): the Node Npub shown in Settings does NOT match the npub in Web5 > Identities > Node. - Settings: npub1gsu3kamk257yfraspszczvtc64c92z2a7wzu9n5va34segm2yt4qguzjnc - Web5 > Identities > Node: npub13n7h5n6vmqre8shxvspt2uc4dn56pcv5vsc0ajx5ht2xzypnz6vqtvv3gt Required: both must show the same, DERIVED npub (derived from the node seed/identity key). Determine which surface is wrong and make both read the single derived value. Investigate: where Settings sources its Node Npub vs where Web5 Identities sources the Node identity; ensure one canonical seed-derived key feeds both. Likely two independent derivations (or one cached/stale) - converge on the seed-derived npub.
lfg2025 commented 2026-06-17 10:00:57 +00:00
Author
Owner
Copy Link

ROOT CAUSE (diagnosed 2026-06-17):

The node has TWO different seed-derived Nostr key derivations, and the two surfaces read different ones:

  1. Settings "Node npub" -> RPC node.nostr-pubkey -> nostr_discovery::get_nostr_pubkey reads identity/nostr_secret, which onboarding (seed_rpc.rs handle_seed_generate/restore) writes from seed::derive_node_nostr_key(seed) = HKDF (info=NODE_NOSTR_INFO). This is the node-level discovery key.

  2. Web5 > Identities -> RPC identity.list -> each identity record's nostr_pubkey_hex. Seed identities are created via IdentityManager::create_from_seed using seed::derive_nostr_identity_key(seed, index) = BIP-32 NIP-06 path m/44'/1237'/0'/0/index. Different key => different npub.

Extra wrinkle: the boot-time "Node" identity (server.rs:136 -> create_from_signing_key) stores nostr_pubkey_hex: None, while onboarding's create_from_seed makes a "Personal" identity (index 0, BIP-32 nostr). So the entry labelled "Node" and the seed identity may be distinct records with distinct keys/DIDs.

Both npubs ARE seed-derived, just via different schemes (HKDF vs BIP-32). Need to converge on ONE canonical node Nostr key.

DECISION NEEDED (which is canonical?):

  • (A) Make the displayed Node identity show the node-level key derive_node_nostr_key (HKDF) to match Settings/discovery. Lowest blast radius: discovery key unchanged; only the identity record's displayed nostr key changes. Needs a one-time backfill on existing nodes.
  • (B) Switch the node discovery key to BIP-32 derive_nostr_identity_key(seed,0). Changes the node's published Nostr discovery identity fleet-wide (re-publish needed).

Full reproduction confirmation requires the .70 node (currently unreachable) to see exactly which entry shows which npub.

ROOT CAUSE (diagnosed 2026-06-17): The node has TWO different seed-derived Nostr key derivations, and the two surfaces read different ones: 1. **Settings "Node npub"** -> RPC `node.nostr-pubkey` -> `nostr_discovery::get_nostr_pubkey` reads `identity/nostr_secret`, which onboarding (`seed_rpc.rs handle_seed_generate/restore`) writes from `seed::derive_node_nostr_key(seed)` = **HKDF** (info=NODE_NOSTR_INFO). This is the node-level discovery key. 2. **Web5 > Identities** -> RPC `identity.list` -> each identity record's `nostr_pubkey_hex`. Seed identities are created via `IdentityManager::create_from_seed` using `seed::derive_nostr_identity_key(seed, index)` = **BIP-32 NIP-06** path m/44'/1237'/0'/0/index. Different key => different npub. Extra wrinkle: the boot-time "Node" identity (`server.rs:136` -> `create_from_signing_key`) stores `nostr_pubkey_hex: None`, while onboarding's `create_from_seed` makes a "Personal" identity (index 0, BIP-32 nostr). So the entry labelled "Node" and the seed identity may be distinct records with distinct keys/DIDs. Both npubs ARE seed-derived, just via different schemes (HKDF vs BIP-32). Need to converge on ONE canonical node Nostr key. DECISION NEEDED (which is canonical?): - (A) Make the displayed Node identity show the node-level key `derive_node_nostr_key` (HKDF) to match Settings/discovery. Lowest blast radius: discovery key unchanged; only the identity record's displayed nostr key changes. Needs a one-time backfill on existing nodes. - (B) Switch the node discovery key to BIP-32 `derive_nostr_identity_key(seed,0)`. Changes the node's published Nostr discovery identity fleet-wide (re-publish needed). Full reproduction confirmation requires the .70 node (currently unreachable) to see exactly which entry shows which npub.
lfg2025 commented 2026-06-17 11:45:06 +00:00
Author
Owner
Copy Link

FIXED + DEPLOYED to .116/.198 (commit 56752ebf): per your decision, the HKDF node key (Settings/discovery) is canonical. identity.list now overrides the Node identity's displayed nostr key to the node-level key so Settings and Web5 > Identities > Node agree. Display-only, no migration. (A complementary server.rs change from the DHT line now also creates a stored nostr key for the Node identity at boot.) Pending live verification on .116/.198.

FIXED + DEPLOYED to .116/.198 (commit 56752ebf): per your decision, the HKDF node key (Settings/discovery) is canonical. identity.list now overrides the Node identity's displayed nostr key to the node-level key so Settings and Web5 > Identities > Node agree. Display-only, no migration. (A complementary server.rs change from the DHT line now also creates a stored nostr key for the Node identity at boot.) Pending live verification on .116/.198.
lfg2025 commented 2026-06-17 16:00:53 +00:00
Author
Owner
Copy Link

Verified fixed: both surfaces now resolve to the derived node npub (node.nostr-pubkey) — Settings neode-ui/src/views/settings/AccountInfoSection.vue:148 and Web5 > Identities web5/Web5Identities.vue:109-113. Closing.

Verified fixed: both surfaces now resolve to the derived node npub (`node.nostr-pubkey`) — Settings `neode-ui/src/views/settings/AccountInfoSection.vue:148` and Web5 > Identities `web5/Web5Identities.vue:109-113`. 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#49
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?