Non-owner members never get agents in desktop/web mention autocomplete (kind-10100 records present and correct; Agent Directory renders them)

Summary

Community members (non-owners) never see agents in the desktop/web mention autocomplete, even when kind-10100 agent-profile records exist on the relay with a respond_to_allowlist that includes the viewer. The Agent Directory on the Agents tab renders the same records correctly for the same viewer — only the composer autocomplete fails. Mobile is unaffected (it resolves mentions from channel members).

Environment

Hosted community (*.communities.buzz.xyz), remote agents per docs/remote-agents.md (systemd launcher, buzz-acp harness, NIP-OA auth tags)
Reproduced on desktop 0.4.26 AND a current 0.5.x client (two different users/machines)
Agents are members of the channels in question, with published kind-0 profiles (carrying valid NIP-OA auth tags) and kind-10100 records

What we established

The desktop app (0.4.26 at least) never publishes kind-10100 records for provider-backed agents. A relay dump (REQ kinds:[10100], NIP-42-authed member) returned zero events in a community with 6 active agents. Owner-side autocomplete works anyway via the local managed-agents registry — so the gap is invisible to the agent owner and hits only other members.
We published complete records ourselves (agent-signed over WS; schema per nostr_convert.rs::agents_from_events): name, display_name, agent_type, status, channels, channel_ids, respond_to: "allowlist", respond_to_allowlist (including the test viewer), channel_add_policy. Accepted (OK true), and readable by a non-owner member over an authenticated REQ.
After that: Agent Directory lists the agents for the non-owner viewer ✓ — but the composer @ autocomplete still offers only humans ✗. Per source (useMentions.ts + agentAutocompleteEligibility.ts), the allowlist branch of relayAgentIsSharedWithUser should admit the viewer and shouldHideAgentFromMentions should show invocable agents, so the data and the visible code both say this should work.

Expected

A member on an agent's respond_to_allowlist (or anyone with a shared channel) should get that agent in mention autocomplete — matching the directory, and matching what the harness would actually accept.

Impact

Remote/provider-backed agents (the architecture docs/remote-agents.md formalizes) are effectively single-player on desktop/web: only their owner can mention them. Teams fall back to mobile or to replying inside agent threads.

Happy to provide the record dumps, event IDs, or run diagnostics against our community.

fix(desktop): let channel-member agents reach the mention picker

Adding a current self-hosted data point from an external Hermes Agent on Windows Desktop 0.5.x.

We now have the inverse half working for the owner account:

complete agent-signed kind:10100 is present;
Desktop recognizes the remote identity as an agent in channel members;
with respond_to=allowlist and the current user's pubkey in respond_to_allowlist, @KITT appears in autocomplete immediately;
the same agent remains absent from the main Agents tab because it has no local managed-agent record ([Bug] Agents created outside the current app-managed store do not appear in the Agents tab #3054/Feature: first-class remotely-hosted agents (display/team membership without local spawn config) + default avatar gallery #4834).

Before changing the record, respond_to=owner-only did not admit the remote agent through current relayAgentIsSharedWithUser() logic. So the full directory payload and invocability fields are definitely being consumed by current Desktop.

This suggests the remaining non-owner failure described here is worth testing specifically against the current allowlist path: a directory-backed external agent can now work on Desktop for the allowlisted owner, so if an explicitly allowlisted non-owner is still filtered, that narrows the bug to viewer/ownership policy rather than relay discovery itself.

Happy to test a non-owner account too if there is a candidate fix/diagnostic branch.

Adding a reproduction with unusually strong isolation, plus one finding that widens the impact beyond the picker.

Setup: self-hosted relay, 11 remote agents (systemd + buzz-acp, NIP-OA auth tags per docs/remote-agents.md), all clients on desktop 0.5.18 (macOS owner + two Windows non-owners).

Server side verified clean at every layer before suspecting the client: kind:10100 records live for all 11 agents with name, respond_to: "allowlist", respond_to_allowlist (containing the affected viewers), channel_ids (containing the shared channels); channels are channel_type: stream; viewers are channel members; NIP-IA archive snapshot contains none of the fleet; the HTTP bridge (POST /query) returns 200s to the affected users throughout. We also ran the 0.5.18 eligibility functions (relayAgentIsSharedWithUser, relayAgentCanRespondInChannel, getMentionableAgentPubkeys, isAgentIdentityInAllowedList) standalone against the exact production values: they admit the viewer. The data and the visible eligibility code both say this should work — matching this issue's original analysis — yet the composer offers only the viewer's locally-managed agents. respond_to: "anyone" + shared channel changes nothing.

A natural experiment that pins the trigger: our agents' kind:0 auth tags were accidentally dropped for ~18h (see #5492 — set-profile builds a fresh kind:0 and silently omits the NIP-OA tag unless BUZZ_AUTH_TAG is set). During that window, with owner_pubkey unresolvable, profiles were classified as humans (is_agent: owner_pubkey.is_some() in nostr_convert.rs) — and non-owner mention autocomplete worked: a non-owner fresh-mentioned an agent (h+p tags, no e), and the agent answered. Restoring the auth tags flipped classification back to agent-owned-by-another-user and the picker hid them again within minutes, same clients, same build. So the hiding is gated precisely on the agent classification path, not on the relay data or the eligibility inputs — consistent with #3671's dead-code analysis of the managed-list guard.

Wider than the picker: while diagnosing we dumped the affected users' outgoing events. Desktop replies carry only e tags — no p tag for the parent author (three samples across three channels, incl. a direct reply to an agent's message in a thread). So the natural fallback — "reply inside the agent's thread" — also never wakes a mention-subscribed agent. Non-owner → agent communication from desktop is fully severed: picker broken, hand-typed names send no p (per #3671), and replies address nobody. Mobile is unaffected, as reported here.

Our interim: BUZZ_ACP_SUBSCRIBE=config with a rules file cloning Mentions mode everywhere plus require_mention = false in dedicated ask-the-agent channels. Works, but it's a harness-side workaround for a client defect.

Happy to supply event dumps or test against a branch — and if it helps land this, we're willing to rebase #3108/#4653 onto current main.

[lenny] integrate REG-4: owner-attested capabilities+model on kind:30…

Navigation Menu

Repository navigation

Non-owner members never get agents in desktop/web mention autocomplete (kind-10100 records present and correct; Agent Directory renders them) #4548

Summary

Environment

What we established

Expected

Impact

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Non-owner members never get agents in desktop/web mention autocomplete (kind-10100 records present and correct; Agent Directory renders them) #4548

Description

Summary

Environment

What we established

Expected

Impact

Activity

hondoaus commented on Aug 15, 2026

Cynthia427 commented on Aug 24, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions