fix(desktop): pin agent instances to their community relay, guard duplicate minting, scope mentions (#2515) - #3221
Closed
jeremyd wants to merge 3 commits into
Closed
fix(desktop): pin agent instances to their community relay, guard duplicate minting, scope mentions (#2515)#3221jeremyd wants to merge 3 commits into
jeremyd wants to merge 3 commits into
Conversation
added 3 commits
July 27, 2026 14:45
A non-empty per-record relay_url now wins at effective_agent_relay_url, the single choke point all agent relay resolution flows through (spawn, restore, reconcile fan-out, profile sync, spawn-hash). An instance minted for a community stays bound to that community's relay no matter which workspace is active when it starts; unpinned records keep the agents-everywhere behavior (block#2122) unchanged. Previously every started instance connected to the active workspace relay, so after a community switch + relaunch an agent could come up under a pubkey the relay had never admitted while mentions kept tagging its real, now-offline instance. Signed-off-by: cloudfodder <cloudfodder@relay.tools>
…ock#2515) create_managed_agent now rejects a new record whose name matches an existing instance in the same relay scope (same pin, or both unpinned), inside the records lock so concurrent creates cannot race past the check. A second keypair for the same @name on one relay is exactly the duplicate-identity state from block#2515: mentions resolve to one pubkey while the other instance answers. Same name on a different relay stays allowed — one identity per agent per community. The guard lives in managed_agents/mint_guard.rs with unit tests; commands/agents.rs only gains the call (narrow ratchet bump). Snapshot/team import paths are untouched; they restore existing records rather than minting new identities. Signed-off-by: cloudfodder <cloudfodder@relay.tools>
…#2515) A managed-agent instance pinned to another community's relay runs — and answers mentions — only there. useMentions now drops such instances from mention candidacy entirely, so a stale channel membership can no longer make the foreign instance win the same-name coalesce over the instance that actually serves the active relay (which left @mentions tagging a pubkey that never answers). The pin comparison lives in foreignPinnedAgentPubkeys.ts with unit tests. The three name-dedupe memos collapse into a shared dedupeTrimmedNames helper to keep useMentions.ts inside the file-size gate. Signed-off-by: cloudfodder <cloudfodder@relay.tools>
Author
|
Looks like I was part of a cohort of users that installed, and tried to use multi-community agents. Which ended up having a mess of agents (multiple key pairs per agent, mention problems, and etc). This was fixed I believe by #2122, but the data itself was not. So I was confused. Closing this PR as I don't think it's necessary now. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #2515, and removes the largest trigger for #2648.
Problem
The create flow mints one record + keypair per (agent, community), but every started instance connects to the active workspace relay. After a community switch + relaunch, an agent comes up under a pubkey the relay never admitted, while @mentions keep tagging its real — now offline — instance. Same-name records from different communities then collide in the mention picker (duplicate targets, missing avatars — this issue), and a second install re-mints identities that already exist (#2648).
Root cause sits in gaps #2122 itself lists as known follow-ups: restore-on-launch is record-level (pair-scoped restore not yet shipped) and the startup reconcile is one-shot. This PR bridges those gaps without changing the agents-everywhere design.
Changes (one commit each)
fix(desktop): honor a managed agent's stored relay pinA non-empty per-record
relay_urlnow wins ateffective_agent_relay_url— the single choke point all agent relay resolution flows through (spawn, restore, reconcile fan-out, profile sync, spawn-hash). An instance minted for a community stays bound to that community's relay regardless of the active workspace. An empty pin is byte-for-byte the existing agents-everywhere behavior (feat(desktop+acp): spawn a harness per (agent, community) pair at GUI startup — warm sockets, lazy LLM pool #2122) — the pin is strictly opt-in.fix(desktop): refuse minting a duplicate agent instance per relaycreate_managed_agentrejects a new record whose name matches an existing instance in the same relay scope (same pin, or both unpinned), inside the records lock so concurrent creates can't race past the check. Same name on a different relay stays allowed — one identity per agent per community. Guard lives inmanaged_agents/mint_guard.rswith unit tests; snapshot/team import paths untouched (they restore records, not mint identities).fix(desktop): scope mention candidates to the active communityAn instance pinned to another community's relay runs — and answers mentions — only there, so
useMentionsdrops such instances from candidacy entirely. A stale channel membership can no longer make the foreign instance win the same-name coalesce over the instance actually serving the active relay. This implements the fix suggested in [Bug] Agents from different communities collide in channels, causing duplicate @mention targets and missing avatars #2515's description. Pin comparison inforeignPinnedAgentPubkeys.tswith unit tests.Design notes
Testing
just ci(fmt + clippy + unit tests + desktop builds) green on top of currentmain(7ca0bbd94).mint_guard.rs,foreignPinnedAgentPubkeys.test.mjs.(If maintainers want it, we also have a follow-up that fans kind-0 profiles out per (agent, relay) pair on spawn and on persona edits — closes the missing-avatar half permanently. Kept out of this PR to keep it reviewable.)