Cross-owner agent mentions are impossible: candidates filtered by local ownership, and eligibility reads a kind (10100) nothing publishes

[rjgalvez]

Describe the bug

An agent owned by one person can never appear in another person's @ mention autocomplete, in any channel, under any configuration. respond_to: anyone, respond_to: allowlist, channel membership, and shared-channel overlap all have no effect.

There appear to be two independent causes, and the second makes the first unreachable.

Cause 1 — the eligibility gate is unreachable for agents you don't own

useMentions.ts applies three gates in order (v0.5.1 desktop/src/features/agents/hooks/useMentions.ts:245-262):

if (isArchivedDiscovery(pubkey)) return;
if (!isAgentIdentityInManagedList(candidate, managedAgentPubkeys)) return;   // :249
if (shouldHideAgentFromMentions({…})) return;                                //  :252

isAgentIdentityInManagedList (lib/agentAutocompleteEligibility.ts:57-65) keeps a candidate only if isAgent !== true or its pubkey is in managedAgentPubkeys. That set is built from useManagedAgentsQuery → the local list_managed_agents Tauri command, i.e. strictly the viewer's own agents — and apply_inbound_managed_agent deliberately refuses to mint one from a relay event (commands/personas/inbound.rs:376-404, "managed agents carry device-local secrets and are never minted from a relay event").

Relay-agent candidates are added with isAgent: true unconditionally (useMentions.ts:334-346), and member candidates get isAgent: true whenever profile?.isAgent === true (:318-323), which for a kind:0 profile is derived as owner_pubkey.is_some() (nostr_convert.rs:345) — always true for an agent, since sync_managed_agent_profile always attaches a NIP-OA owner attestation (relay.rs:401-455).

So for any viewer who does not own the agent, the candidate is dropped at :249 before shouldHideAgentFromMentions / relayAgentIsSharedWithUser ever run.

Typing the mention manually doesn't help either: extractMentionPubkeys (:794-831) resolves p tags from mentionMapRef plus the post-filter mentionCandidates, so no p tag is emitted for a filtered-out agent.

Cause 2 — relayAgentIsSharedWithUser reads an event kind nothing publishes

Even if Cause 1 is fixed, the eligibility logic is inert. relayAgentIsSharedWithUser (lib/agentAutocompleteEligibility.ts:12-31) reads channelIds / respondTo / respondToAllowlist from a RelayAgent, which comes from list_relay_agents (desktop/src-tauri/src/commands/agent_discovery.rs:1057-1074) — a query for exactly [{"kinds":[10100]}].

Nothing in the repo publishes a kind:10100 agent profile. The only 10100 writer is buzz channels set-add-policy (crates/buzz-cli/src/commands/channels.rs:1004-1038), whose content is {"channel_add_policy": …}. Agent identity is published as kind:0 plus kind:30177 (managed_agents/agent_events.rs), and the persona catalog as kind:30175. The eligibility path never consults 30177.

Consequently agents_from_events (nostr_convert.rs:445-496) defaults channel_ids: [] (:469-480) and leaves respond_to absent → respondTo: null (shared/api/tauri.ts:686-695), so relayAgentIsSharedWithUser returns false for every agent and every viewer.

Secondary effect: publishing a 10100 makes things worse. directoryAgentPubkeys is every pubkey in relayAgentsQuery.data, with no eligibility filter (useMentions.ts:182-190), and for a channel member shouldHideAgentFromMentions ends in return directoryAgentPubkeys.has(normalized) (agentAutocompleteEligibility.ts:85-97). So a 10100 that doesn't satisfy relayAgentIsSharedWithUser converts "unknown invocability ⇒ show" into "explicit exclusion ⇒ hide", removing an agent that channel members could previously see. Note also that 10100 is replaceable-by-pubkey, so publishing one destroys that agent's existing channel_add_policy event.

Steps to reproduce

1. User A creates an agent, sets Responds to: Anyone, and adds it as a member of a channel shared with user B.
2. Confirm on the relay that the agent's kind:30177 content has "respond_to":"anyone" (visible in agents/retention/<64hex>.db, table persona_events).
3. As user B, in that shared channel, type @ followed by the agent's exact name.
4. The agent never appears in the autocomplete — no entry, and no "not in channel" label.

Same result with Responds to: Allowlist containing user B's 64-char hex pubkey.

Expected behavior

An agent whose owner has set respond_to: anyone (or an allowlist including the viewer) and which shares a channel with the viewer should be selectable in that viewer's mention autocomplete — which is what relayAgentIsSharedWithUser and the respond_to setting both clearly intend.

Version and platform

• Buzz version: 0.5.1 (verified unchanged in 0.5.2 — agentAutocompleteEligibility.ts, agent_discovery.rs, agent_events.rs are all identical between the two tags)
• OS: macOS 15 (Darwin 25.4.0), Apple Silicon

Logs / additional context

The agent-side gate is configured correctly and is not the problem: record.respond_to reaches the harness as --respond-to at spawn (managed_agents/runtime.rs:380-392), and author_allowed admits any author under RespondTo::Anyone for non-DM channels (crates/buzz-acp/src/lib.rs:250). The agent would answer; it simply cannot be addressed, because no p tag can be produced for it.

Possible fix directions (happy to open a PR if you can indicate a preference):

1. Cause 1 — allow a candidate through :249 when its pubkey is in relayAgentsQuery and it passes relayAgentIsSharedWithUser, rather than requiring local ownership; and relax the corresponding early-return in extractMentionPubkeys so the p tag is emitted.
2. Cause 2, option (a) — add a kind:10100 agent-profile publisher on the owner's desktop. Needs a new projection plus a source for channel_ids, which doesn't exist today.
3. Cause 2, option (b) — repoint list_relay_agents at kind:30177 (which already carries respond_to / respond_to_allowlist) and resolve channel membership with a kind:39002 #p query, the same one the harness already uses at relay.rs:651-668. This needs no relay change and seems the cleaner shape.

Workaround for anyone hitting this: skip mentions entirely by setting per-agent env BUZZ_ACP_SUBSCRIBE=all (plus BUZZ_ACP_KINDS=9 and BUZZ_ACP_CHANNELS=<uuid> to avoid wildcard kinds and unintended channels), which makes the agent answer messages in a scoped channel without requiring a p tag.

[rjgalvez]

I found the way to make it work via env variables of agents BUZZ_ACP_SUBSCRIBE to subscribe to a channel and BUZZ_ACP_CONFIG with a .toml file:

name = "sales-questions"
  channels = ["eb6651f1-4437-41c9-9fe4-ea498ad5e704"]
  kinds = [9]
  require_mention = false
  filter = 'str_starts_with(content, "?")'

so it only answers messages that starts with "?", plus instructions to answer in thread (agent was not sending messages)

[KokyCode]

While @rjgalvez fix is great, it's just more feasible mentioning the agents instead. Please fix asap

[rjgalvez]

@KokyCode yes, its a workaround that we found in our team and works, but of course it's more friendly to mention

[AlanSobenes]

Confirming on Windows and on 0.5.3 — this reports macOS and 0.5.1/0.5.2, and nothing has changed.

Setup: self-hosted relay, three users, each running desktop-managed agents. Symptoms match exactly, and in both directions simultaneously — A cannot mention B's agents while B cannot mention A's, in channels where all parties and the agents are members. The agents' own messages render normally in those channels, so publishing works and only addressability fails. The symmetry is useful confirmation that this is structural rather than per-account misconfiguration: it reproduces without either side having touched the other's settings.

Verified against 0.5.3 (desktop/src-tauri 0.5.3): agentAutocompleteEligibility.ts, the kinds: [10100] query at agent_discovery.rs:1054, and the single 10100 writer at crates/buzz-cli/src/commands/channels.rs:1038 are all unchanged from your description.

One detail relevant to fix option (b) that I don't see called out: the kind:30177 snapshot is built from the definition-tier fields, not the runtime ones — desktop/src-tauri/src/managed_agents/agent_snapshot.rs:194-209:

// Use definition-level fields (respond_to, allowlist, parallelism) for
respond_to: record.definition_respond_to.clone(),
respond_to_allowlist: record.definition_respond_to_allowlist.clone(),

The harness, meanwhile, is spawned from the instance-level record.respond_to / record.respond_to_allowlist. These diverge in practice — on this machine an agent held definition_respond_to: "anyone" with an empty definition allowlist while its running process reported respond_to=allowlist(2) with two keys. Repointing list_relay_agents at 30177 would therefore advertise a policy the agent doesn't enforce, in either direction: visible-but-silent, or answers-but-hidden. Worth reconciling the two tiers, or sourcing the projection from the instance fields.