fix(desktop): shared relay agents are un-mentionable/un-addable — let directory eligibility run

[leesalminen]

Closes #2603

Summary

A shared relay agent (kind:0 + NIP-OA auth tag, kind:10100 directory profile with respond_to: anyone, channel member) responds fine when p-tagged, but nobody except its owning device can @-complete it or add it to channels: addCandidate in useMentions.ts drops every agent-flagged identity that isn't in the local managed-agents list before shouldHideAgentFromMentions runs, making the directory-eligibility path (mentionableAgentPubkeys, and the "Invocable => always show" / member Option-B rules) unreachable for foreign agents. MembersSidebar applies the same managed-list-only gate to add-member search.

Changes

• useMentions.ts: remove the pre-emptive isAgentIdentityInManagedList gate. shouldHideAgentFromMentions is the single authority — it already shows invocable agents (local managed ∪ relay-directory-eligible), hides non-member non-invocable ones, and applies the member/directory rules. Local managed agents are unaffected (they're seeded into mentionableAgentPubkeys), and other members' owner-only agents stay hidden (non-member + non-invocable, or member + directory-excluded).
• MembersSidebar.tsx: add-member candidates now pass when the agent is locally managed or relay-directory invocable by the current user (new relayAgentIsInvocableByUser: respond_to: anyone, or an allowlist containing them). Channel overlap is deliberately not required here — adding the agent to the channel is what creates the overlap.
• agentAutocompleteEligibility.ts: new relayAgentIsInvocableByUser helper; relayAgentIsSharedWithUser delegates its allowlist branch to it (behavior unchanged); doc comment on isAgentIdentityInManagedList clarifying the caller-supplied allow-set contract.

Test plan

• node --import ./test-loader.mjs --experimental-strip-types --test on agentAutocompleteEligibility.test.mjs: 22/22 (4 new: invocable-by-user modes, and a regression test that a directory-eligible member agent is shown without a local managed entry).
• biome check and tsc --noEmit clean on touched files.
• Manually verified against a self-hosted multi-tenant relay running a headless shared agent (buzz-acp + kind:10100, respond_to: anyone): with this fix the agent appears in mention autocomplete and add-member search on a desktop that does not manage it.

🤖 Generated with Claude Code

[jonathanleiva15]

Confirming the root cause from another angle in case it's useful for the review.

Repro (mobile↔desktop parity): an externally-attested agent — one that joined a community via a NIP-OA owner auth tag (ViaOwner relay membership) and is a channel member — is mentionable in the mobile client but not in desktop, on the same account/relay. Mobile's buildMentionCandidates (mobile/lib/features/channels/mentions/mention_candidates.dart) adds all channel members unconditionally and only applies the invocability filter to non-members, so membership is sufficient there. On desktop, isAgentIdentityInManagedList (added in #2149) runs inside addCandidate before shouldHideAgentFromMentions and drops any isAgent && !managedAgentPubkeys.has(pk), so a member agent I don't locally manage never reaches the directory gate. Removing that pre-gate (this PR) restores the mobile semantics 👍

One sanity check for the review: #2149's stated intent was narrower than "managed-only" — de-duping owner-less stale p-tag copies of a persona I already manage (e.g. Bumble). Removing the gate entirely also lets owner-less member duplicates back in. If preserving that dedupe matters, a more surgical variant exempts only member + attested agents:

if (candidate.isAgent !== true) return true;
if (managedAgentPubkeys.has(normalizePubkey(candidate.pubkey))) return true;
return candidate.isMember === true && Boolean(candidate.ownerPubkey);

ownerPubkey is only set for a verified auth tag (profile_valid_oa_owner_pubkey in nostr_convert.rs), so it discriminates a legit external agent from a stale owner-less copy — and shouldHideAgentFromMentions still hides the "Fizz" (directory-excluded) case either way. Both approaches fix the reported symptom; just flagging the trade-off in case the owner-less dedupe was intentional. Happy to send a follow-up with tests if the surgical variant is preferred.

[Bartok9]

Collaborative review (Bartok9)

Thanks @leesalminen — this is the cleanest desktop-only fix of the #2987 swarm I’ve looked at.

What’s strong

1. Right authority: dropping the managed-list pre-gate in useMentions so shouldHideAgentFromMentions actually runs for external agents matches the diagnostic (#2987 report point 1).
2. Add-member circularity fixed deliberately: relayAgentIsInvocableByUser (anyone/allowlist, no channel-overlap requirement) is the right split from relayAgentIsSharedWithUser for “invite path.”
3. Tests of the regression: shouldHideAgentFromMentions: relay-shared agent shows without local managed entry + invocable helper cases — this is what reviewers need when five PRs claim the same one-line gate.
4. Doc comment on isAgentIdentityInManagedList: renaming the mental model to caller-supplied allow-set is worth more than another prose PR body.

Suggestions (non-blocking unless maintainers want polish first)

1. Owner self-mention edge (#3448’s isOwnAgent / respond_to: owner-only): with only relayAgentIsInvocableByUser, owner-only self agents on a remote host may still not mention/add themselves. Worth either:
   • a short “Out of scope / parented in #2987 footing / follow-up” note, or
   • a small additive own-pubkey escape aligned with 3448 if maintainers want one carrier for both.
2. Name drift: helper is isAgentIdentityInManagedList but set is now “addable/mentionable.” A rename is optional and debatable (API churn); a one-line doc is already good.
3. Call-site parity: only sidebar uses the expanded allow-set assembly; mentions relies on hide helper. That’s fine if getMentionableAgentPubkeys already unions managed ∪ invocable relay — a one-sentence call-path claim in the PR body would help maintainers grepping later (Brad-class: prove path, don’t just assert).

Swarm coordination (not a code nit)

Several open PRs touch the same gate (#3110, #3292, #2752, #3108, #3448, …). Prefer this + or #3448 as the merge vehicle so the thrash collapses. Happy to re-test a tip commit after rebase onto current main if useful.

Verdict: Approve-shape from a third-party collab angle — small, tested, correct layer. Not a maintainer formal approve.

[Cyberworkshop]

Heads up for whoever picks this as the merge vehicle: fixing the picker-eligibility gate alone won't fully close out #2950 for existing agents. Found and verified a second, separate bug while reproducing this end-to-end on my own relay — Edit Agent's "Who can talk to this agent" toggle doesn't reliably persist to the on-disk managed-agents.json respond_to field the harness actually reads (stuck at owner-only despite the UI showing "Anyone," even across an explicit restart). Full repro with timestamped before/after is on #2950's latest comment — once this merges, worth checking that agents whose access was changed post-creation actually respond, not just that they're visible in the picker.

[Bartok9]

Thanks @bharani-gif for the approve — appreciated.

@Cyberworkshop good catch on the separate track. Agree this PR should stay scoped to picker/directory eligibility (managed-list pre-gate + invocable add-member path). The Edit Agent “Who can talk to this agent” → on-disk managed-agents.json respond_to stuck at owner-only while the UI shows “Anyone” is a distinct persistence/harness bug and won’t be closed by merging #2605 alone.

For whoever drives merge of this vehicle:

1. Land fix(desktop): shared relay agents are un-mentionable/un-addable — let directory eligibility run #2605 (or the chosen External (non-desktop-managed) agents: publishing kind:10100 makes them un-mentionable — shouldHideAgentFromMentions's invocability logic is unreachable #2987-family carrier) for mention/add visibility.
2. Treat the Managed agent invisible/unresponsive to other community members even after setting "Who can talk to this agent" to Everybody #2950 repro you linked (issue comment) as a follow-up — verify post-create access toggles actually rewrite harness respond_to, not just the UI label.
3. After merge, smoke both: shared agent appears in autocomplete and a toggled-to-Anyone agent actually answers non-owners.

Happy to re-test a tip commit after rebase onto current main if useful. Not claiming maintainer merge authority — just collab coordination so #2950 doesn’t get marked done on visibility alone.