buzz-acp: BUZZ_AUTH_TAG never reaches a headless agent's kind:0 profile — NIP-OA sibling admission silently fails until a manual set-profile

[madisonicus]

Describe the bug

For a headless / hand-provisioned agent, setting BUZZ_AUTH_TAG in the agent's environment and restarting buzz-acp is not sufficient to make NIP-OA sibling admission work — and nothing tells you why.

The sibling gate (author_allowed → is_owner_or_sibling → check_sibling_via_profile) verifies the owner attestation by reading the author's stored kind:0 profile on the relay. But BUZZ_AUTH_TAG only injects the tag into events the client happens to sign, and buzz-acp never publishes or refreshes a kind:0 at startup. So the tag sits in the environment, the relay keeps serving the old un-tagged profile, and every sibling-authored event is silently dropped by the recipient's author gate. From the operator's seat this is indistinguishable from an idle agent.

Steps to reproduce

1. Two agents, same owner, hand-minted identities (no desktop involvement), both relay members, both respond_to=owner-only.
2. Owner computes valid NIP-OA tags (buzz-sdk compute_auth_tag example) for both agent pubkeys; each agent gets BUZZ_AUTH_TAG=<tag json> in its env; both processes restarted. Startup even logs owner resolved from BUZZ_AUTH_TAG: <owner> — which reads like success.
3. Agent A mentions agent B (kind 9, correct p tag, verified in the relay's events table). B never fires a turn. No log line on either side.
4. Query B's view of A's kind:0: still the pre-tag profile from initial provisioning.
5. Workaround that fixes it: from A's environment, run buzz users set-profile --name <same> --about <same> — the CLI injects the auth tag into the freshly signed kind:0. Restart B (see buzz-acp: owner-only sibling gate caches a transport failure as not-a-sibling, silently blacklisting a teammate bot until restart #5450 — the negative sibling verdict is cached). Sibling admission then works immediately; measured end-to-end at 47 s mention→turn.

Expected behavior

Setting BUZZ_AUTH_TAG and restarting the agent should be sufficient for sibling admission (or the startup log should say the profile still lacks the tag), rather than requiring an undocumented manual set-profile.

Version and platform

• Buzz version: relay + buzz-acp built from rev 96ae141 (2026-08-06)
• OS: relay in Docker on Debian 13 (x86_64); agents on Debian (aarch64 and x86_64), self-hosted single-community relay, require_relay_membership=true, allow_nip_oa_auth=true

Logs / additional context

Startup logs owner resolved from BUZZ_AUTH_TAG: <owner-pubkey> and nothing else; the drop is silent on both sides. Relay's stored kind:0 for the sender (read via psql) confirmed tag-less until the manual set-profile, and tag-carrying immediately after.

Suggested fix: at buzz-acp startup, when BUZZ_AUTH_TAG is set, fetch own kind:0 from the relay; if absent or missing/mismatching the auth tag, republish the profile (preserving existing content fields). That makes the env var self-sufficient, matches what the startup log already implies, and costs one read + at most one write per boot. Docs alternative if the republish is unwanted: the BUZZ_AUTH_TAG documentation should state that a headless agent must run buzz users set-profile once after the tag is set or changed.

Related: #5450 (the cached negative sibling verdict makes this worse — even after the profile is fixed, the recipient must restart) and #4223 (different layer: relay-side attestation materialization; this issue is client-side publication).

Happy to send the buzz-acp startup-republish patch as a DCO-signed PR if the approach sounds right to maintainers.

[samsymbia]

Confirming on relay 40220d5 (v0.2.1), and adding one visible consequence beyond sibling admission: the desktop also decides whether to show a key as an agent from this same kind:0 (profile_valid_oa_owner_pubkey in desktop/src-tauri/src/nostr_convert.rs). So a headless buzz-acp agent with a valid BUZZ_AUTH_TAG keeps appearing as a person on its profile — no agent drawer — until its profile is republished with the tag.

Our workaround was buzz users set-profile --name "<current name>", run with the agent's own BUZZ_PRIVATE_KEY and BUZZ_AUTH_TAG in the environment. sign_event injects the tag, and set-profile's read-merge-write keeps the other fields. Worth pairing with #5751, since running the same command without the tag drops it again.

Prior art for the fix: a different harness's Buzz channel plugin handles this on startup. It compares its stored profile's auth tag with the configured one (hasConfiguredAuthTag), and if they differ, republishes the profile with the tag, replacing any other auth tag and keeping the rest (resolveProfileTags). Doing the same in buzz-acp at startup would close this.