fix(desktop): route same-owner remote agent mentions - #5484
Open
dafacto wants to merge 1 commit into
Open
Conversation
Signed-off-by: dafacto <matt@dafacto.com>
dafacto
marked this pull request as ready for review
August 11, 2026 07:43
rmichelena
added a commit
to rmichelena/buzz
that referenced
this pull request
Aug 14, 2026
…tries An agent whose `respond_to` is `owner-only` — the harness default, so the common case — is excluded by `relayAgentIsSharedWithUser` for everyone, including the person the policy names as the only allowed sender. The eligibility layer cannot fix that on its own: neither `RelayAgentInfo` nor the TS `RelayAgent` carries an owner, so it has no way to ask whether the viewer owns the agent. `relay_enrich` already resolves each agent's NIP-OA owner from its kind:0 — it has to, to verify kind:30177 authorship before a record may seed or override a directory entry. The owner was simply not exposed. This carries it through to the frontend so an owner-aware admission branch (block#5484) has the data without a second kind:0 round trip. No eligibility behaviour changes here. `owner_pubkey` is populated and otherwise unread, so the directory stays the only thing this PR alters. `None`/`null` means unresolved, not unowned. On a closed relay the NIP-OA owner frequently never materializes on the agent's kind:0 (block#4223, relay-side fix in block#5581), and headless agents are exactly the population that runs there — so a consumer must treat absence as "unknown" rather than as a negative answer. A test pins that the field serializes as `owner_pubkey`, not `ownerPubkey`: the Tauri payload contract is snake_case and `fromRawRelayAgent` does the camelCase mapping, so a rename would silently land `undefined` on the TS side with nothing failing. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Signed-off-by: Roberto Michelena <77797875+rmichelena@users.noreply.github.com>
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
1 participant
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.
Summary
respond_to: "nobody"Root cause
The composer allow-list treated the local managed-agent store as the primary source of agent identity. On another Buzz client, a channel could contain an agent owned and hosted by the same user, but that client had no local managed record for the pubkey. The remote member was therefore filtered from autocomplete or could be confused with a local instance lifecycle.
This change treats verified NIP-OA ownership plus active channel membership as the remote routing signal, scoped only to channel composers. Admission waits for a successful relay-directory response so an explicit heartbeat-only policy cannot be missed during startup or directory errors.
User impact
A user can mention an agent hosted by another Buzz client in a shared stream or forum. Buzz sends the mention to the exact existing pubkey; local managed-agent setup remains untouched. Active Huddles reuse the existing remote-pubkey synchronization path.
Fixes #3277.
Validation
LGTM WITH NITSafter independent TypeScript, Biome, Rust, unit, and focused browser verificationcargo fmt --checkpassedScope
This deliberately does not broaden direct-message or community-search agent discovery, and it does not make a remote identity a local managed instance.