block / block/buzz

Desktop: @-mention autocomplete surfaces archived and profile-less orphan identities

Open
#7,251 0 comments 0 reactions 0 assignees View on GitHub
Dominant language
Rust
Stars
32.7k
Forks
4.3k
Avg merge
1d 13h
Merged PRs (30d)
253

Description

**Describe the bug**

The Desktop @-mention autocomplete offers identities that should never be valid mention targets, which is confusing when composing a message. Two kinds of dead identity leak into the picker:

1. **Archived identities.** Three duplicate agent identities were archived by their owner (NIP-IA archive, kind:9035) and now appear in the relay archive snapshot (kind:13535), yet they still show up in the @-picker:
- `fb726ed389a1e2ea105680186029a71a3a66e2540ed5268feb9fb6b95b061f5e`
- `451425f4a2d20997e9b133294c674e6d6628215da1e19fc9d5b6e12c39967338`
- `5190c66ce5b2a2dda851c96f043bfdc9cc88f8294f83e469e8735671b9edb095`

2. **A profile-less orphan identity minted by community create→delete.** Creating a community, then removing it, left behind a signing identity that was never cleaned up:
- `a02ac2eb782310f42e5dac7504972e2e4bdb0f58ffdfca5114f1c87be3c6cb6f` (npub tail `…8n5a4z`)
- It has **no published profile** (`missing_profile` — no kind:0), **no owner** (`owned_by_me: false`), and is a member of **zero channels**. Nobody holds its private key, so it cannot be self-archived or deleted, and it is not in the archive snapshot. Yet Desktop still surfaces it in the @-picker as a phantom entry.

The owner does not want (and cannot get) a database deletion — the identity can remain inert in the relay. The actual defect is that the **client offers it as a mention target**.

**Steps to reproduce**

Orphan case:
1. Create a community, then delete it (an agent signing identity is minted by the create flow and left behind on delete).
2. In any channel, type `@` in the composer.
3. The orphaned, profile-less identity appears in the autocomplete dropdown.

Archived case:
1. Archive a duplicate agent identity (owner-signed, kind:9035; confirm it lands in `buzz agents archived` / kind:13535).
2. Restart Desktop, type `@` in the composer.
3. The archived identity still appears in the autocomplete.

Confirmed from the relay side: `buzz users get --name --owner ` still returns all archived duplicates alongside the live identity; `buzz agents archived` confirms they are archived.

**Expected behavior**

The @-mention autocomplete should exclude any identity that is **any** of:
- present in the archive snapshot (kind:13535), OR
- `missing_profile` (no kind:0 profile event), OR
- not a member of the channel being composed in.

A profile-less, ownerless orphan fails all three and should never be offered. (This is a client-side filter — no DB change required.)

**Nice-to-have (separate, lower priority)**
- `community delete` should reap the signing identities its create flow minted.
- An owner-facing path to remove/hide an orphaned identity that has no recoverable key.

**Version and platform**
- Buzz version: unknown (Desktop, owner account; relay `growthsystems.communities.buzz.xyz`)
- OS: macOS

**Logs / additional context**

Possibly related: #5163 (owner-reviewed agent drafts can leave orphan profiles without runnable records), #2423 (renaming/re-adding personal agents desyncs identity and breaks @mentions), #7222 (remote ACP bots missing from the mention dropdown — the inverse filtering problem), #5667 (RFC: ghost-key repair / body registry). This report is specifically about **dead/archived/orphaned identities appearing in the picker when they should be filtered out.**

Contributor guide

Open the contributing guide

Research direction

Start at Desktop's @-mention autocomplete in the message composer and trace how identities are loaded and filtered. Reproduce with an archived identity and a profile-less orphan, then verify the picker excludes archived identities, missing-profile identities, and identities outside the current channel; the issue does not name specific files or tests.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
desktop
Issue type
Bug
Difficulty
3/5
Estimated time
1-2 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
68/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.