Multi-device: mention picker cannot reach remotely-hosted agents (owner-only unhandled, directory never updated, replies never p-tag authors)
- Dominant language
- Rust
- Stars
- 32.7k
- Forks
- 4.3k
- Avg merge
- 1d 13h
- Merged PRs (30d)
- 253
Description
**Setup:** one user, two devices, same key. Device A's Buzz Desktop hosts the agents; device B is a pure client (same identity imported). Community = the user + their agents.
**Symptom:** on device B the @ picker offers no agents at all (only the user's own name). Plain-typed @names and thread replies publish but notify nobody, and agents wake only on p-tagged events (buzz-acp shipped default `subscribe = "mentions"` with `require_mention = true`, `crates/buzz-acp/src/config.rs`) — so device B has no channel path to reach any agent. (Deployments can override via `BUZZ_ACP_SUBSCRIBE` / `BUZZ_ACP_NO_MENTION_FILTER`; this issue describes the code default.)
**Defect 1 — eligibility:** `desktop/src/features/agents/lib/agentAutocompleteEligibility.ts` — `relayAgentIsSharedWithUser()` handles `respondTo` `allowlist`/`anyone` only; no `owner-only` branch, and `RelayAgent` carries no `ownerPubkey` (the kind:10100 card has no owner field), so owner-only agents are hidden even from their own owner on every non-hosting device.
**Defect 2 — settings cannot propagate:** Desktop saves respond-to edits into the owner-side kind:30177 managed-agent record, but the picker reads kind:10100 cards — and repo-wide the only kind:10100 writer is `buzz-cli channels set-add-policy` (content = `{"channel_add_policy"}` only). No code path ever writes or updates `respond_to`/`channel_ids` on the card, so switching an agent to Anyone/Selected-people can never make it picker-visible on another device.
**Defect 3 — replies never p-tag the parent author:** `thread_tags()` in `crates/buzz-sdk/src/builders.rs` emits only NIP-10 `e`-tags; Desktop's `messageMentionPubkeys.ts` states "Stream messages notify only explicit mentions." So "reply to a message to reach its author" is impossible for every client, which removes the natural fallback for defects 1-2.
**Defect 4 — misleading dialog copy:** the Selected-people edit dialog tells the owner "you don't need to add yourself" (`desktop/src/features/agents/ui/RespondToField.tsx:334`), but picker eligibility checks the literal published allowlist — following the dialog makes the fix silently fail even once defect 2 is repaired.
**Suggested direction:** publish `ownerPubkey` on the directory card and add an owner-only branch; republish (or relay-derive) directory data when respond-to changes, or let a client read its own owner's kind:30177 records; p-tag the parent author on replies per NIP-10; fix the dialog copy.
**Impact:** every multi-device user; becomes fleet-wide once agents run headless/remote (VPS), where every client is a non-hosting device.
Contributor guide
Research direction
Start with desktop/src/features/agents/lib/agentAutocompleteEligibility.ts, RespondToField.tsx, and messageMentionPubkeys.ts, then trace kind:10100 and kind:30177 handling plus thread_tags() in crates/buzz-sdk/src/builders.rs. Confirm how respond-to changes and reply tags are published. Done means remote clients can discover eligible agents, settings take effect, replies p-tag authors, and the Selected-people copy matches eligibility behavior.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust, typescript
- Domain
- backend-api-design, desktop, distributed-systems
- Issue type
- Bug
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Clearly specified
- Newbie friendliness
- 35/100