[Bug] Agents from different communities collide in channels, causing duplicate @mention targets and missing avatars

[jw-gsl]

Describe the bug

When the same Buzz Desktop user belongs to two communities and has a personal agent with the same display name in each community, agent identity is not consistently scoped to the active community.

The Agents view shows only the agent belonging to the current community, but a channel in that community can contain both communities' agent identities. A single @agent-name mention can then produce multiple Nostr p tags, notifying both identities. In the observed case, the identity associated with the other community replied, and its profile picture did not render because its image URL referenced the other community's media host.

This leaves the user unable to understand or manage the collision from the current Agents view: only one agent is visible there, while the channel and mention resolver operate on two same-named identities.

Belonging to multiple communities should be supported. The bug is the leakage or retention of an agent identity from one community inside another community's channel and mention-resolution context.

To Reproduce

The following is the observed sequence. The precise operation that first introduced the foreign agent membership has not yet been isolated:

1. Sign in to Buzz Desktop with a user who belongs to two separate Buzz communities.
2. Have a personal agent in each community with the same display name, for example a renamed default agent.
3. In Community B, open the Agents view and observe that only the Community B agent is shown.
4. Add or re-add the Community B agent to a channel in Community B.
5. Restart Buzz Desktop or switch between the two communities.
6. Return to the Community B channel and type @<agent-name>.
7. Send the message.
8. Inspect the channel membership and the sent Nostr event.
9. Observe that:
   • both the Community A and Community B agent identities are channel members;
   • one friendly-name mention produces p tags for both same-named identities;
   • the identity associated with Community A can reply in the Community B channel; and
   • its avatar may be blank because its profile image URL points to Community A's media host.

Expected behavior

• Agents, profiles, memberships, runtimes and media should be scoped to the active community unless an explicit cross-community action is supported.
• A channel in Community B should not silently retain or add an agent identity from Community A.
• Selecting one agent in the mention picker should add exactly one p tag for that agent's immutable identity.
• Same-named agents should be disambiguated in the UI using community, owner, status and/or a stable unique handle.
• The current community's Agents view and channel membership controls should expose the same manageable set of agent identities.
• Switching communities or restarting Desktop should reconcile stale or foreign agent memberships rather than preserving an invisible collision.
• Profile pictures should not silently fail because an identity unexpectedly references another community's authenticated media host.

Supporting Material

All real names, community URLs, channel IDs, event IDs and public keys have been removed from this public report.

In the affected Community B channel:

Check	Observed result
Agents view	One agent with the affected display name
Profile lookup by display name	Two profiles with different immutable identities
Profile image hosts	One on Community A; one on Community B
Channel membership	Both agent identities present
One @<agent-name> message	Notification tags for both identities
Reply sender	Identity whose profile referenced Community A
Avatar	Blank in the Community B conversation

Useful diagnostic commands with placeholders:

buzz users get --name <agent-display-name>
buzz channels members --channel <community-b-channel-id>
buzz messages thread --channel <community-b-channel-id> --event <thread-root-id>

Raw identifiers and events can be supplied privately if required.

Environment

• OS: macOS 26.5.2
• Buzz Desktop: 0.4.22
• Configuration: one Desktop user signed in to two hosted Buzz communities
• Affected surfaces: Agents view, community switching, channel membership, mention resolution and avatar loading
• Date observed: 23 July 2026

Additional context

This may share a root cause with agent identity drift after rename or re-add operations, but it exposes a distinct multi-community isolation problem:

1. The Agents view appears community-scoped.
2. Channel membership and profile/name resolution are not producing the same scoped result.
3. Friendly-name resolution notifies every matching identity instead of requiring one stable selection.
4. Cross-community media references can leave the selected sender without an avatar.

Suggested permanent fix:

• Namespace all agent registry, profile-cache, membership, mention-resolution and runtime records by community/relay plus immutable agent ID.
• Never resolve a mention from display name alone; persist and use the exact identity selected in autocomplete.
• Prevent or warn about duplicate display names within a channel, and show Name · community · owner · status when ambiguity exists.
• Reconcile channel memberships against the current community's agent registry at startup, after community switching and after agent edits.
• Provide a migration or cleanup path for already-stored foreign or stale memberships.
• Add end-to-end tests covering one user, two communities, same-named agents, restart/community switching, a single mention, reply routing and avatar loading.

[jw-gsl]

Additional verified root-cause evidence

Further inspection of the local managed-agent registry, runtime logs, PID records and relay events confirms that this is more than stale mention autocomplete:

• Two managed instances legitimately existed for the same persona, one for Community A and one for Community B. Their existence alone is expected.
• The registry still associated the Community A agent identity with Community A's relay.
• Buzz Desktop nevertheless launched that exact Community A identity against Community B's relay. The runtime log and PID record both showed the mismatched identity/relay pairing.
• The foreign runtime discovered Community B's channels, subscribed to them and published online presence there.
• The correct Community B instance was offline, while both identities remained channel members. A single friendly-name mention therefore emitted two p tags, and the Community A identity replied inside Community B.
• Removing the foreign membership caused that runtime to unsubscribe from the affected channel. Starting and adding the correct Community B instance then produced a single correct mention target and a successful reply.

The logs do not identify the exact UI action that caused the cross-community launch. A persona update occurred shortly beforehand, but treating that as the trigger would be speculation.

This evidence supports the existing cross-community identity-scoping issue rather than a separate defect. It also suggests an additional invariant for the fix: the launcher should treat community/relay, immutable agent identity, credentials, memberships and profile/media metadata as one atomic scoped record, and refuse to start a runtime when the selected identity's registered community does not match the target relay.

Recommended regression coverage:

1. Configure one user with two communities and one same-persona agent instance in each.
2. Switch communities, edit the shared persona, restart Desktop and start/stop each instance.
3. Assert that each runtime connects only to its registered relay and discovers only that community's memberships.
4. Assert that one selected mention produces exactly one p tag for the community-correct identity.
5. Assert that a foreign identity cannot remain silently attached to a channel after community switching or reconciliation.