Un agente miembro del relay no puede agregarse a un canal — los 3 caminos devuelven éxito sin efecto

[A-PachecoT]

Contexto

Una identidad de agente que entra al relay por invitación queda miembro de la comunidad pero no de ningún canal, y no encontramos ningún camino programático para agregarla a un canal. El agente puede leer y escribir igual, pero no aparece en la lista de miembros, no sale en el autocompletado de @, y el diálogo de agregar miembro del Desktop dice No matching people or agents sin ofrecer botón.

Reproducido con 4 identidades nuevas (Chaski, Temis, Mercurio, Quipu) el 2026-08-26 contra buzz.cofoundy.dev.

Lo que SÍ está correcto (verificado del lado del servidor)

• Los 4 están en el roster del relay: kind:13534 lista 12 miembros e incluye a los 4 (tags member, no p).
• Sus kind:0 existen y la búsqueda FTS del relay los encuentra: POST /query con {"kinds":[0],"search":"Chaski"} devuelve 1 hit.
• Llevan atestación NIP-OA válida: el kind:0 trae ["auth", <owner>, "kind=0", <sig>] y la firma verifica BIP-340 contra el pubkey del owner.
• No están archivados: buzz agents archived devuelve {"archived":[]}.
• El agente está conectado por WebSocket y autentica NIP-42 sin problemas.

Los 3 caminos que fallan

1. buzz channels add-member --channel <uuid> --pubkey <hex> [--role bot] → relay error 400: invalid: missing p tag. El CLI construye el kind:9000 sin el tag p. Falla igual con --role, con el --auth-tag global, y tanto si lo manda un admin como si el agente se auto-agrega.
2. POST /events con el kind:9000 bien formado ([["h",<channel>],["p",<pubkey>]], firmado por el agente) → responde {"accepted":true} y la membresía no se aplica. channels members sigue igual.
3. WebSocket (wss://), NIP-42 autenticado (OK true), mismo kind:9000 → responde ["OK",<id>,true,""] y tampoco se aplica.

En los tres casos el status reportado es de éxito y el efecto no ocurre, que es la parte más cara: sin sondear channels members uno se queda creyendo que funcionó.

Referencia del comportamiento esperado

crates/buzz-test-client/tests/e2e_relay.rs §test_nip29_put_user_self_add_bypasses_policy documenta que un agente siempre puede auto-agregarse con kind:9000 + tags h/p. El test está marcado #[ignore], así que no corre en CI y no hay evidencia de que el path esté vivo en este build.

Qué hay que averiguar

• ¿Se aplica NIP-29 kind:9000 en este build del relay, o solo se persiste el evento?
• ¿Cómo entró Probe al canal pilot-agentes con role=bot? Es la única prueba de que existe un camino que funciona.
• ¿Por qué el diálogo del Desktop no ofrece agregar una pubkey pegada, si AddMemberDialog.tsx tiene la rama directResult justamente para eso?

Método de verificación

export BUZZ_RELAY_URL=https://buzz.cofoundy.dev BUZZ_PRIVATE_KEY=<llave del agente>
buzz channels members --channel 32fd4fb9-3ab1-447c-b000-aafc4a8e7934

Queda arreglado cuando el agente aparece en esa lista y su nombre autocompleta con @ en el canal.

Guardrails

• Verificar con channels members, nunca con el accepted/OK de la respuesta. Los tres caminos devuelven éxito sin aplicar nada.
• No abrir el canal a más agentes mientras esto no se entienda: un agente que responde pero al que nadie puede mencionar parece roto y confunde al equipo.

Refs

• products/cantera/playbook/building-agents/buzz-agents.md §5 (footguns) — la regla falsa que esto corrigió: "la membresía del relay ya habilita los canales"
• handbook/infrastructure/SYSTEMS.md § Buzz — canales e IDs