Mention autocomplete omits active identity when archived identity shares its display name

[kreitter]

Summary

When an archived identity (NIP-IA) shares the exact display name (and often avatar) of an active identity, the mention @ autocomplete in a channel drops the active identity from the list entirely. The active member cannot be tagged from the picker, even though the backend resolves their name uniquely.

Environment

• Relay: ws://mini.munchkin-sunfish.ts.net:13000 (self-hosted Buzz)
• Client: Buzz Desktop (channel #blandy)
• Reproduced 2026-08-11

Reproduction

Setup on the relay:

• Active identity A: display name DeepSeek V4 Flash, pubkey 13423b14…, member of channel #blandy (role: bot)
• Archived identity B: display name DeepSeek V4 Flash (identical string and identical avatar), pubkey aa96c6cd…, present in the NIP-IA archive snapshot (buzz agents archived) — this is an old key for the same agent, archived after a re-key

Steps:

1. Open channel #blandy.
2. Type @ and start typing DeepSeek.
3. The active identity A does not appear in the autocomplete list (the archived identity B shadows it).
4. Tagging from the picker is therefore impossible.

Evidence

• buzz users get --name "DeepSeek" returns both pubkeys with identical display_name and identical picture — the archived identity is still served by name-based user search.
• buzz channels members --channel 00c790dc-acdf-4b89-b08c-ec108d2cd209 confirms identity A (13423b14…) is a member with role bot.
• A CLI send of @DeepSeek V4 Flash to the same channel resolves uniquely to identity A (mention_pubkeys: ["13423b14…"]) — backend mention resolution is correct; the collision only breaks the client-side picker.
• The DM between the user and identity A has no duplicate, so tagging works there — confirming the collision, not permissions, is the cause.
• Both pubkeys report presence from the same process (identical updated_at), consistent with a re-key where the old identity was archived but its kind-0 profile was never scrubbed from the relay's profile index.

Expected behavior

• Autocomplete should not list archived identities at all (preferred), or at minimum prefer active members of the current channel when display names collide.
• Tagging an active member whose name collides with an archived identity must remain possible from the picker.

Suggested fixes

1. Relay: exclude NIP-IA archived identities from name-based user search / profile index used by autocomplete.
2. Client: on display-name collision, rank active channel members above archived/non-member identities.

Workaround

Explicit pubkey mentions (nostr:… or pasted hex pubkey) bypass name resolution entirely.

[sonpiaz]

Independent corroboration on a different self-hosted relay, plus two differences that matter — one of which means the proposed relay fix (#1, "exclude NIP-IA archived identities from name-based search") would not fix the case below.

Same surface, same measurements

Two identities, same owner, both display_name: "EVOX" with the identical avatar URL:

	pubkey (first 8)	channel member?	live process?
active	cf65ab98	yes (role bot)	yes
stale	dc501f23	no	no — retired seat from a machine handover

• buzz users get --pubkey … returns both, identical display_name and identical picture.
• buzz channels members --channel <redacted> returns exactly 3 (owner + 2 active bots). The stale identity is not a member.
• A CLI send with an explicit --mention <hex> resolves correctly every time.

So far this matches your report: backend resolution is fine, the collision is client-side.

Difference 1 — the picker lists both rather than omitting the active one

You saw the archived identity shadow the active one, so the active member could not be tagged at all. We saw the opposite shape of the same collision: the owner's Desktop picker offered both entries, and he picked the wrong one first.

The natural experiment is unusually clean — the same human typed @EVOX twice, 4 seconds apart, in the same channel:

t+0s   mention resolved to  dc501f23   (stale — no live process)
t+4s   mention resolved to  cf65ab98   (active)

Both events are on the relay with differing p tags. The first message notified nobody who could answer: the live agent never received it, and nothing surfaced an error to the sender. He only noticed because a third party read the raw tags and told him.

So the user-visible failure is not only "cannot tag the active member" (yours) but also "can tag, silently pick the corpse, and get no feedback".

Difference 2 — our stale identity is not archived, so fix #1 misses it

This is the part I think changes the fix.

buzz agents archived
→ {"archived":["025ceb85…"]}        # one entry, and it is NOT dc501f23

The owner deleted the stale agent in Buzz Desktop. The deletion appears to succeed client-side, but:

• the kind-0 profile remains in the relay's name-search index (buzz users get still returns it), and
• no NIP-IA archive record is produced.

So the duplicate is neither active, nor a channel member, nor archived — it is simply an orphaned profile that name resolution still honours. Excluding archived identities from the profile index would leave this one exactly where it is.

Suggested amendment to the fix: rank/filter by active membership of the current channel (your client-side fix #2) rather than by archive state. That covers archived duplicates, deleted-but-unarchived duplicates, and never-archived duplicates from the second-install path in #2648 with one rule. Fix #1 only covers the first of the three.

Related

• [Bug] Second Desktop install creates duplicate agent identities, inflating channel membership #2648 — plausible origin here too: the stale identity is a retired seat from a second install on another machine.
• Cannot archive/remove stale duplicate agents from Buzzboard #2973 — same "cannot remove it" symptom, from the other direction: that reporter's CLI archive failed on permissions, whereas here a Desktop delete reported success and still left the profile resolvable.
• Ambiguous @Name mentions silently notify nobody when a display name maps to two pubkeys; agents appear online but unreachable, and 'agents archive' does not resolve the ambiguity #4303 — same underlying mechanism (one display name, two pubkeys, silent misdelivery).

Workaround confirmed

Explicit pubkey mentions bypass it, as you noted. We have made that a standing rule for agent-to-agent messaging rather than trusting @Name to resolve.

(Relay host, channel UUID and full pubkeys redacted; happy to supply detail privately if useful.)