`buzz channels add-member` manda el kind:9000 sin el tag `p` → 400 invalid: missing p tag

[A-PachecoT]

Contexto

Agregar una identidad a un canal privado es hoy un acto manual por el Buzz Desktop porque el CLI no puede hacerlo. Los dos caminos programáticos fallan:

• buzz channels add-member --channel <uuid> --pubkey <hex> construye el kind:9000 (NIP-29 add-user) sin el tag p, y el relay lo rechaza con 400 invalid: missing p tag.
• El bridge HTTP POST /events es un falso positivo: responde accepted:true y no aplica la membresía. NIP-29 se procesa por WebSocket, no por el bridge.

Esto no es cosmético. Al 2026-08-26 cada persona del equipo emite una identidad <persona>-cc para su Claude Code, y cada -cc necesita un add-member por canal privado que su dueño quiera que vea (founders, clientes, pets, infra). Con 5 personas son 20 operaciones manuales de Desktop que deberían ser una línea de script. Sin la membresía el agente no rebota en silencio: send corta con relay error 400: restricted: not a channel member cuando el mensaje ya está redactado.

Fix propuesto

En el constructor del evento kind:9000 de channels add-member, emitir el tag p con la pubkey del miembro (hex) además del tag h del canal. Mismo trato para remove-member (kind:9001) — verificar si comparte el bug antes de tocarlo.

Si el CLI publica por el bridge HTTP y no por WebSocket, el fix del tag no alcanza: hay que rutear los eventos NIP-29 por WS. Determinar cuál de los dos es el bug real es el primer paso.

Criterios de aceptación

1. buzz channels add-member --channel <uuid> --pubkey <hex> sale con exit 0 y la membresía queda aplicada.
2. remove-member revierte.
3. Un canal PRIVADO al que se agregó una identidad por CLI aparece en buzz channels list corrido con la llave de esa identidad.
4. El comando falla ruidosamente (exit != 0) si el relay no aplicó la membresía — nunca accepted:true sobre un no-op.

Método de verificación

Contra el relay vivo, con una llave de owner y una identidad de prueba en pilot-agentes:

# 1. antes: el canal privado NO aparece para la identidad de prueba
BUZZ_PRIVATE_KEY=$TEST_KEY buzz channels list | grep -c '<nombre-del-canal>'   # espera 0

# 2. agregar por CLI con la llave del owner
BUZZ_PRIVATE_KEY=$OWNER_KEY buzz channels add-member \
  --channel <uuid> --pubkey <hex-de-prueba>; echo "exit=$?"                    # espera exit=0

# 3. después: el canal SÍ aparece — esta es la sonda, no el exit code
BUZZ_PRIVATE_KEY=$TEST_KEY buzz channels list | grep -c '<nombre-del-canal>'   # espera 1

El paso 3 es el que cuenta. El exit 0 del paso 2 ya miente hoy por el bridge HTTP.

Guardrails

• NO uses buzz channels members para verificar — cuelga sin timeout en nuestro build (junto con messages list). La sonda es channels list con la llave del miembro.
• No pruebes contra un canal con gente. pilot-agentes existe para esto.
• No toques el gate humano de emisión de identidades (buzz agents draft-create abriendo el Desktop). Ese gesto es deliberado y se queda; este issue es solo sobre la membresía de canal, que hoy es trabajo mecánico disfrazado de decisión.

Scope y referencias

• Fork: cofoundy/buzz. Ver si el bug existe upstream (block/buzz) antes de escribir el fix — el precedente de handbook#2 es que ya había PRs allá y se portó en vez de escribirse.
• handbook/infrastructure/buzz/BITACORA.md §Reglas — la membresía privada y su sonda
• handbook/infrastructure/buzz/bitacora/2026-08-26-membresia-privada-de-agentes.md — el rebote que lo destapó
• cantera/playbook/building-agents/buzz-agents.md:216 — el footgun documentado (citaba #3, que es un PR mergeado de otra cosa; este issue lo reemplaza)
• cofoundy-toolkit:buzz → references/setup.md §Paso 4 — la guía que hoy manda al Desktop por esto

---

https://claude.ai/code/session_01J7c8pSc5toH5BaBSCYo14z