Desktop drops relay-directory agents from the mention picker when it doesn't manage them locally

[kaalph]

Setup

I run a self-hosted relay with five communities on it. The agents aren't started from the desktop app — they're containers on my own VM, one per agent, each running buzz-acp with its own key. They're managed with docker compose and a config repo, like everything else on that box. Each one publishes its kind:0 profile and a kind:10100 directory entry, and they're proper channel members.

Desktop 0.5.4 on Windows.

What happens

None of them show up in the @ autocomplete or in "Add people and agents". They're in the channel, the relay knows them, their profiles render fine on messages they send — but I can't mention them from the composer.

The gate is in desktop/src/features/messages/lib/useMentions.ts:249:

if (!isAgentIdentityInManagedList(candidate, managedAgentPubkeys)) {
  return;
}

managedAgentPubkeys only contains agents the desktop manages itself. Anything else gets dropped before shouldHideAgentFromMentions ever runs, so the finer policy below it never sees these candidates. Same helper is used for the add-picker path.

Took me a while to find, because the agents answer normally if I reply in a thread — it's only the composer that can't reach them.

Why the provider path doesn't help me

I read docs/remote-agents.md after 0.5.4 landed. I get the model and I like it — the k8s provider is nice work. It doesn't fit here though, and not because of the substrate:

I don't want another binary on my desktop, and I don't want deploy credentials for that VM sitting on my laptop. The whole reason the agents live on the server is that the server is the thing that's administered, backed up and running 24/7. Deploying them is a compose file, not a click. So the desktop never holds their keys and never needs to.

That's the case I think isn't covered right now: agents deployed out-of-band, announced through the relay, with the desktop as a pure client.

What I'm asking for

Treat directory agents as first-class in the composer. Either of these would do it for me:

1. Let isAgentIdentityInManagedList accept the already-computed invocable/directory set as a third argument, so directory-announced agents pass the gate and shouldHideAgentFromMentions keeps deciding the rest.
2. Or simpler: an agent that is a member of the current channel is always mentionable, regardless of who manages it.

I've been running (1) plus (2) as a local patch for about a week across five communities and haven't hit a downside — the existing hide rules still do their job, and nothing foreign leaks in because directory entries are scoped to the relay you're connected to.

Happy to open a PR if you want it, or to test a different approach if you'd rather solve it another way. I'm also fine being told this is out of scope — then I'll keep the patch.

Not asking for

A docker provider. I don't think you should write one for my setup. The directory already carries everything the client needs to know.

[tetra878]

Reproducing the same behavior on a self-hosted, single-host setup (Linux; local buzz-relay + Buzz Desktop on the same machine):
One external agent runs under systemd via buzz-acp (not Desktop-managed), respond gate set to anyone.
The agent is a member of five channels (stream and dm types), has a kind:0 profile, shows presence online, and replies normally when p-tagged directly (e.g. from a DM).
It never appears in the @ mention autocomplete in any channel type, and cannot be selected as a recipient at all.
We also tried publishing a kind:10100 profile manually (name / channel_ids / respond_to) to satisfy the directory-based eligibility path, with no effect. If I read #4994 correctly, the relay currently expects channel_add_policy on kind:10100, so an ACP-driven agent effectively cannot have a usable directory entry today — meaning the eligibility path cannot be satisfied and the managed-list gate silently drops the agent from the picker in every channel.
So currently a self-hosted ACP agent is fully functional but unmentionable from Desktop, with no user-side workaround. Either proposed direction in this issue (accepting the precomputed directory set, or treating any channel-member agent as mentionable) would fix our case. Happy to test a patch on our setup.

[kaalph]

@tetra878 One thing that might save you a round: the fix for the gate you're describing is merged but not released. #4913 went into main on 5 Aug at 18:15; desktop-v0.5.5 was tagged 4 Aug. I checked with git merge-base --is-ancestor — 0.5.5 doesn't contain it, and there's no 0.5.6 yet. If you're on a release build, the managed-list gate is still there and no directory entry, valid or not, will get you past it.

On the 10100 collision: your reading matches the source. KIND_AGENT_PROFILE is 10100 (crates/buzz-core/src/kind.rs:87, "Agent metadata + owner reference, replaceable, agent-authored"), and buzz channels set-add-policy publishes {"channel_add_policy": ...} on that same kind (crates/buzz-cli/src/commands/channels.rs:1035). Replaceable, same author — so whichever went out last silently overwrites the other. #4994 splitting them onto 10100/10101 looks like the right call.

That said, I don't think the collision is what's biting you, and here's why I doubt it. Our directory entries are intact profiles — name, display_name, agent_type, respond_to, status, channels, channel_ids, capabilities, no channel_add_policy anywhere. We never touched the add-policy command, so nothing overwrote them. The agents were still unmentionable on 0.5.1 through 0.5.5. The entry was fine; the gate dropped it before anything looked at it.

So I'd expect your case to be the same gate rather than a broken entry, and I'd retest on a build with #4913 before spending time on the directory shape. If it still fails after that, then the entry matters and it's worth digging.

For what it's worth we gave up on the directory path and hand-wrote managed-agents.json entries instead, which got the agents visible and then broke mentions a different way — that one's #5099, separate bug, separate code path.

25 agents here across six communities, self-hosted relay, same "functional but unmentionable" symptom you describe. Happy to test a patch too.