← Volver al listado de tecnologías ← Índice de Buzz para Administradores

Qué es Buzz y por qué un relay propio

6 de agosto de 2026 Por: Artiko

buzznostrrelayself-hostingadministracionarquitectura

Qué es Buzz y por qué un relay propio

Este es el primer capítulo de un curso dirigido a la persona que va a operar un relay de Buzz: instalarlo, configurarlo, exponerlo a internet, hacerle backup, actualizarlo y responder cuando algo se rompe a las 3 de la mañana. No es un curso de uso de la aplicación de escritorio ni de escritura de agentes. Y antes de tocar un solo comando hay que entender qué es la pieza que vas a administrar, porque el modelo mental de Buzz no se parece al de un Slack autohospedado ni al de un GitLab: si arrancas con el modelo equivocado, la mitad de las decisiones de configuración de los capítulos siguientes te van a parecer arbitrarias.

La frase corta

El README del proyecto lo resume en una línea:

A workspace where humans and agents build together, on a relay you own.

Un workspace donde humanos y agentes construyen juntos, sobre un relay que es tuyo. Las tres partes de esa frase son literales y cada una tiene consecuencias operativas:

Workspace: no es un servidor de chat con bots enchufados. Es la superficie completa de trabajo de un equipo: canales, hilos, DMs, foro, canvases, media, búsqueda, workflows, repositorios git y registro de auditoría.
Humanos y agentes: los agentes de IA no son integraciones externas con un webhook. Son miembros con su propio par de claves, su propia membresía de canal y su propio rastro de auditoría.
Un relay que es tuyo: el servidor lo corres tú (o alguien a quien le pagas por hospedarlo), y ese servidor es la única fuente de verdad del workspace.

Buzz es un relay Nostr

Esta es la afirmación central del proyecto y conviene tomarla al pie de la letra. El README lo dice sin rodeos:

It’s a Nostr relay: every message, reaction, workflow step, review approval, and git event is a signed event in one log.

Cada mensaje, cada reacción, cada paso de un workflow, cada aprobación de un code review y cada evento de git es un evento firmado en un único log. La misma forma, el mismo modelo de identidad y el mismo rastro de auditoría, sea que el autor sea una persona o un proceso.

La forma de un evento

Un evento Nostr, según NIP-01, es un objeto JSON con seis campos:

{
  "id":      "<sha256 de la serializacion canonica>",
  "pubkey":  "<clave publica secp256k1, hex>",
  "kind":    "<entero sin signo>",
  "tags":    [["e", "<event-id>"], ["p", "<pubkey>"]],
  "content": "<payload JSON o texto plano>",
  "sig":     "<firma Schnorr sobre id>"
}

El campo kind es el único switch de despacho. El relay enruta, almacena y hace fan-out de eventos basándose en el kind. Los clientes filtran suscripciones por kind. Una feature nueva es un número de kind nuevo, y eso significa cero cambios rompientes para los clientes existentes.

Buzz reserva rangos de kind así:

Rango	Significado
0–9999	Kinds estándar de Nostr, de NIP-01 en adelante
10000–19999	Eventos reemplazables, NIP-16
20000–29999	Eventos efímeros: no se almacenan, no se auditan
30000–39999	Eventos reemplazables parametrizados
40000–49999	Kinds propios de Buzz

La fuente de verdad del listado vigente es crates/buzz-core/src/kind.rs, que exporta el registro completo como ALL_KINDS: &[u32]. Ahí verás que un mensaje de canal, un paso de workflow, una entrada de auditoría y un patch de git conviven en la misma tabla con kind distinto:

// Todos son eventos. Solo cambia el entero.
KIND_STREAM_MESSAGE          // 9      mensaje de chat en un canal
KIND_REACTION                // 7      reaccion NIP-25
KIND_GIT_PATCH               // 1617   patch NIP-34
KIND_WORKFLOW_TRIGGER        // 46020  disparo de workflow
KIND_APPROVAL_GRANT          // 46030  aprobacion concedida
KIND_AUDIT_ENTRY             // 48001  entrada del log de auditoria

Por qué esto importa al administrar

Un único log significa que una sola base de datos contiene la conversación, el código revisado, la decisión de merge y la evidencia de quién aprobó qué. Tres consecuencias directas:

Un solo backup importa de verdad. No hay que sincronizar el respaldo del chat con el del issue tracker con el del CI. Hay que respaldar Postgres, el object storage y las claves. Lo verás en detalle en Backups, migraciones y actualizaciones.
Un solo control de acceso. La membresía de canal es la única compuerta. No hay una matriz de permisos por producto. Lo verás en Membresía, roles y moderación.
Un solo índice de búsqueda. La búsqueda full-text vive dentro de la propia tabla events de Postgres. No hay un servicio de búsqueda separado que aprovisionar. Lo verás en Búsqueda y registro de auditoría.

El concepto de community y la regla de la URL

Aquí está la regla operativa más importante de todo el curso. Una community de Buzz es el workspace al que un usuario llega por URL. El README lo define así:

A Buzz community is the workspace a user reaches by URL. In the single-relay setup that ships today, the relay URL selects exactly one community. […] the URL is authoritative for the workspace, and all tenant-observable state under that URL is community-local.

Traducido a reglas de operación:

La URL es autoritativa para el workspace. El dominio por el que entra la conexión determina qué comunidad ve el cliente. No lo determina un token, ni un header de aplicación, ni un tag que mande el cliente.
En el despliegue de un solo relay que se envía hoy, la URL del relay selecciona exactamente una comunidad. Con N=1, el nivel de comunidad no agrega nada observable.
Un operador hospedado puede servir muchas comunidades detrás de muchos dominios o subdominios. La regla de cara al cliente no cambia.

Esta regla no es una convención de documentación: está implementada como el paso 0 del ciclo de vida de la conexión. Antes de que cualquier handler pueda observar un dato de tenant, el servidor resuelve el TenantContext a partir del host de la petición.

sequenceDiagram
    participant C as Cliente
    participant R as buzz-relay
    participant DB as Postgres

    Note over R: Paso 0 — Community binding<br/>resolve_host del host de la peticion
    Note over R: Paso 1 — Adquirir permiso del semaforo de conexiones
    R->>C: Paso 2 — AUTH con challenge
    C->>R: Paso 3 — AUTH con evento firmado
    R->>R: Pending pasa a Authenticated o a Failed
    Note over R: Paso 4 — recv_loop, send_loop, heartbeat_loop
    C->>R: EVENT / REQ / CLOSE
    R->>DB: consulta o insercion
    Note over R: Paso 5 — Cleanup y liberacion del permiso

Dos detalles que un administrador debe interiorizar desde ya:

En modo multi-comunidad, un host desconocido o no mapeado se rechaza genéricamente y nunca cae a un tenant por defecto. Esto evita el peor bug posible de un multi-tenant: filtrar datos del vecino por una entrada de DNS mal escrita.
Los tags #h que manda el cliente siguen siendo identificadores de canal, pero deben resolver a un canal dentro de la comunidad derivada del host. La tenencia nunca se deriva de datos controlados por el cliente.

Todo el capítulo Multi-tenant se apoya en esta regla.

Aislamiento y portabilidad de identidad

Dos matices del documento de visión, útiles cuando pregunten si los datos están mezclados con los del vecino:

El aislamiento es la frontera, no un filtro. Las comunidades que comparten infraestructura no pueden verse entre sí: ni sus eventos, ni sus perfiles, ni sus DMs, ni sus resultados de búsqueda, ni sus cadenas de auditoría, ni sus strings de error. La especificación docs/spec/MultiTenantRelay.tla mecaniza ese aislamiento en TLA+ y la autorización en Tamarin.
La identidad es portable, los perfiles son por comunidad. Tu par de claves es tuyo en todas las comunidades; tu perfil, tus DMs y tu contenido sin canal viven por comunidad. Republicas tu perfil en cada comunidad a la que te unes.

Arquitectura en una pantalla

El README trae este diagrama; aquí está convertido a Mermaid:

flowchart TD
    subgraph clientes["Clientes"]
        human["Cliente humano<br/>Buzz desktop"]
        agent["Agente IA<br/>Goose, Codex, Claude Code"]
        cli["CLI y scripts<br/>buzz-cli"]
        acp["buzz-acp<br/>puente ACP y MCP"]
    end

    agent --> acp

    relay["buzz-relay<br/>NIP-01 · auth NIP-42 · REST de canales, DMs, media, workflow y git · audit log"]

    human -->|WebSocket| relay
    acp -->|WS y REST| relay
    cli -->|WS y REST| relay

    relay --> pg["Postgres<br/>eventos y busqueda full-text"]
    relay --> redis["Redis<br/>pub/sub, presencia, rate limits"]
    relay --> s3["S3 o MinIO<br/>media Blossom y objetos git"]

Tres dependencias reales, no negociables hoy: Postgres, Redis y un almacenamiento de objetos compatible con S3. El bundle de producción de deploy/compose/ incluye las tres. El relay expone tres puertos, tal como declara el Dockerfile con EXPOSE 3000 8080 9102:

Puerto	Qué sirve
`3000`	WebSocket NIP-01, REST, documento NIP-11 y la UI web
`8080`	`/_liveness`, `/_readiness`, `/_status`, `/_mesh`
`9102`	`/metrics` para Prometheus

Que la salud y las métricas vivan en puertos distintos del tráfico de aplicación es deliberado: te permite exponer solo el 3000 a internet y dejar 8080 y 9102 en la red interna. Eso se cubre en Observabilidad y en Seguridad en producción.

Un workspace de crates de Rust

El backend es un workspace de Cargo con crates enfocados. El principio arquitectónico literal de ARCHITECTURE.md es que el relay es la única fuente de verdad: buzz-relay importa y orquesta a todos los subsistemas llamándolos directamente, y los subsistemas están aislados entre sí.

flowchart TD
    core["buzz-core<br/>cero I/O"]
    core --> db["buzz-db<br/>Postgres"]
    core --> auth["buzz-auth<br/>NIP-42 y NIP-98"]
    core --> pubsub["buzz-pubsub<br/>Redis"]
    core --> search["buzz-search<br/>FTS de Postgres"]
    core --> audit["buzz-audit<br/>cadena de hashes"]
    core --> wf["buzz-workflow<br/>YAML as code"]
    db --> relay["buzz-relay<br/>el servidor Axum"]
    auth --> relay
    pubsub --> relay
    search --> relay
    audit --> relay
    wf --> relay

El detalle crate por crate, con el pipeline completo de ingesta de un evento, es el capítulo Arquitectura del relay.

Qué reemplaza

La apuesta del proyecto, en palabras del README, es que una comunidad puede hacer lo que hoy los equipos simulan con “chat, forges, bots, dashboards de CI, herramientas de release, índices de búsqueda y una pila de código pegamento”. No todo de golpe y no por arte de magia, pero con un solo sustrato en lugar de siete pestañas que fingen conocerse. En concreto, sobre un solo relay conviven:

Categoría	Qué provee Buzz
Chat	Canales Stream en tiempo real, hilos, reacciones, DMs de hasta 9 participantes, indicadores de escritura
Foro	Hilos asíncronos de formato largo, para lo que no cabe en un canal
Forge	Hosting de repositorios git por smart HTTP, patches y estados NIP-34, anuncios de repositorio
CI y automatización	Workflows YAML-as-code con triggers de mensaje, reacción, calendario y webhook
Búsqueda	Full-text sobre Postgres, con permisos aplicados y un solo índice para todo
Auditoría	Log append-only encadenado con SHA-256, por comunidad
Media	Subidas Blossom BUD-01/BUD-02 sobre S3 o MinIO, con miniaturas generadas en el servidor
Voz	Huddles sobre un relay Opus por WebSocket integrado en `buzz-relay`, sin SFU externo. Sin grabación ni publicación por pista

La consecuencia práctica que más se nota: buscas auth refresh una vez y te salen el reporte del bug, la discusión del canal, los patches, los resultados del CI y el documento de diseño que motivó todo. Una sola consulta, porque todo es el mismo tipo de cosa.

Qué NO es

El README tiene una sección explícita para esto y vale citarla completa, porque te va a ahorrar discusiones:

No es blockchain. Los eventos firmados son útiles sin obligar a nadie a comprar una moneda conmemorativa. No hay cadena de bloques, ni consenso distribuido, ni token.
No es un plan de reemplazo de humanos. Buzz funciona mejor cuando los humanos siguen en el bucle y los agentes se quedan en la sala.
No está terminado. Textual: “We will tell you what works and what doesn’t.”

A eso hay que agregar algunas cosas que Buzz tampoco es, y que salen de leer el código:

No es una federación. Un relay es una isla con una frontera clara. La portabilidad la da tu par de claves, no una replicación entre servidores.
No es cifrado extremo a extremo por defecto. El modelo es TLS en tránsito y cifrado en reposo delegado a la capa de almacenamiento, por ejemplo TDE de Postgres o cifrado de volumen. El cifrado gestionado por el servidor cubre cada canal, cada DM y cada evento, lo que permite eDiscovery sobre todo. NIP-44 extremo a extremo para DMs figura como consideración futura.
No es un servicio sin operación. Corres infraestructura: alguien mantiene, respalda y atiende la alerta de las 3 AM cuando se llena el disco.

Qué funciona hoy y qué se está cableando

Esta es la tabla que el README publica bajo el título “Works today · Being wired up · Strong opinions, pending code”. La reproduzco tal cual porque para un administrador es la diferencia entre prometer algo y quedar mal:

✅ Funciona hoy	🚧 En cableado	💭 Opiniones fuertes, código pendiente
Relay, canales, hilos, DMs, canvases, media, búsqueda, audit log	Clientes móviles, iOS y Android, en Flutter	Reputación web-of-trust entre relays
App de escritorio, Tauri más React	Compuertas de aprobación de workflow, la infraestructura existe pero el pegamento aún está secando	Notificaciones push
`buzz-cli`, agent-first, JSON de entrada y JSON de salida, más el harness ACP para Goose, Codex y Claude Code	Eventos de ciclo de vida de huddle	Features de cultura
Workflows YAML con triggers de mensaje, reacción, calendario y webhook
Eventos de git NIP-34: patches, anuncios de repositorio, estados
Backend de hosting de git

El propio README pone la advertencia debajo: “Please do not plan your compliance program around the 💭 column yet.” No planifiques tu programa de cumplimiento alrededor de la tercera columna todavía.

Dos precisiones adicionales que salen de leer VISION.md y que conviene tener a mano cuando alguien te pida una feature:

Compuertas de aprobación de workflow: el esquema, los endpoints REST, la herramienta MCP y la interfaz existen. El ejecutor todavía no persiste el token de aprobación ni suspende la ejecución; una corrida que llega a un paso request_approval se marca como fallida. La infraestructura está, el cableado es lo siguiente.
Huddles: aquí el repositorio se contradice a sí mismo y conviene saberlo antes de prometer nada. La tabla del README pone “eventos de ciclo de vida de huddle” en la columna 🚧, mientras que VISION.md afirma que “la voz, el ciclo de vida de la sala y los eventos de ciclo de vida están cableados” y ARCHITECTURE.md repite lo mismo en su tabla de limitaciones verificadas, precisando que el relay emite los eventos de participante entrando y saliendo y de huddle terminado. Lo que las tres fuentes sí afirman igual es el límite: la grabación y la publicación por pista tienen kinds reservados y ningún productor. Trátalo como “funciona pero es reciente”: pruébalo antes de comprometerlo.

Licencia y quién está detrás

Licencia: Apache 2.0. El archivo LICENSE de la raíz es la Apache License Version 2.0 de enero de 2004, íntegra. El chart de Helm publicado declara la misma licencia.
Construido por: Block, Inc. El pie del README lo declara explícitamente: “Apache 2.0 · Built by Block, Inc.”, y home y sources apuntan a https://github.com/block/buzz.
Gobernanza: GOVERNANCE.md es un puntero de una línea a la información de gobernanza de proyectos open source de Block, en github.com/block/.github/blob/main/GOVERNANCE.md.

Que sea Apache 2.0 importa operativamente: puedes desplegarlo comercialmente sin pedir permiso y la cláusula de patentes te cubre. No hay edición enterprise con features retenidas; el mismo código base OSS sirve para un relay de una comunidad y para un despliegue hospedado con miles.

Las tres rutas de adopción

El README organiza el arranque por perfil. Te interesan las tres, porque vas a tener que explicárselas a tu equipo.

flowchart LR
    inicio["Quiero usar Buzz"]
    inicio --> a["Solo probar la app"]
    inicio --> b["Relay hospedado sin gestionar servidores"]
    inicio --> c["Construir y correr desde fuente"]

    a --> a1["Descargar el build empaquetado<br/>del ultimo release de GitHub"]
    b --> b1["Plantilla de Railway<br/>boton Deploy on Railway"]
    c --> c1["git clone, Hermit, just setup, just build"]

    a1 --> nota["Sin relay propio la app apunta<br/>por defecto a ws localhost 3000"]
    c1 --> nota2["Relay local en ws localhost 3000<br/>y app de escritorio"]

Ruta 1: la app empaquetada

Para quien solo quiere probar la aplicación, hay builds empaquetados en el último release del repositorio. Los nombres de archivo publicados son:

Plataforma	Archivo
macOS, Apple Silicon	`Buzz_<version>_aarch64.dmg`
macOS, Intel	`Buzz_<version>_x64.dmg`
Linux, x86_64	`Buzz_<version>_amd64.AppImage` o `Buzz_<version>_amd64.deb`
Windows, x64	`Buzz_<version>_x64-setup_alpha-unsigned.exe`

Dos advertencias documentadas que te van a llegar como tickets de soporte. El build de Windows no está firmado con code signing, así que SmartScreen puede mostrar “Windows protected your PC” en el primer arranque: la salida es More info y luego Run anyway. Y en Windows la herramienta de shell del agente corre comandos bajo bash, así que hay que instalar Git for Windows, que trae Git Bash, que es lo que Buzz resuelve en tiempo de ejecución; para otro shell compatible se apunta la variable BUZZ_SHELL.

Por defecto la app se conecta a ws://localhost:3000. Para apuntarla a un relay tuyo o a uno que te compartieron, se define BUZZ_RELAY_URL antes de lanzarla, o se cambia el relay desde dentro de la aplicación.

Ruta 2: relay hospedado en Railway

Para correr un relay para tu equipo sin administrar servidores, el README enlaza una plantilla de Railway desplegable con un clic:

Plantilla: https://railway.com/deploy/buzz-relay-block
Detalle: el post https://engineering.block.xyz/blog/run-your-own-buzz-relay del blog de ingeniería de Block

Aquí hay que ser honesto con un límite: el repositorio no contiene ningún archivo de configuración de Railway. No hay railway.json, ni railway.toml, ni nixpacks.toml. La definición de la plantilla vive del lado de Railway y el procedimiento detallado vive en ese post externo.

Lo único técnico que el repositorio sí dice sobre Railway está en la documentación de S3, y es un dato que te va a morder si lo ignoras: los buckets nuevos de Railway Storage exigen addressingStyle: virtual, es decir https://bucket.endpoint/key. El bundle de Compose de producción fija path y no es configurable por .env para un proveedor S3 externo, así que para Railway Storage hay que usar el chart de Helm o una configuración de Compose propia. Esto se desarrolla en Relay gestionado: Railway y Kubernetes con Helm y en Medios y almacenamiento de objetos.

Ruta 3: build desde fuente

Esta es la ruta del desarrollador y del self-host. El README pide Docker y Hermit, o bien Rust 1.88+, Node 24+, pnpm 10+ y just. El rust-toolchain.toml fija el canal en 1.95.0, que es lo que Hermit descarga. Una sola vez:

git clone https://github.com/block/buzz.git && cd buzz
. ./bin/activate-hermit   # toolchain pinneada, las herramientas se descargan al primer uso
just setup && just build

just setup ejecuta just bootstrap automáticamente: copia .env.example a .env si hace falta, descarga todas las herramientas necesarias vía Hermit y arranca los servicios de Docker más las migraciones.

Cada día:

. ./bin/activate-hermit
just dev   # arranca el relay y la app de escritorio juntos

El relay queda en ws://localhost:3000 y la app de escritorio aparece sola. Para un flujo con terminales separadas, con los logs del relay aparte de la salida de Vite, se usa just relay en una terminal y just desktop-dev en otra.

Un matiz que sorprende a muchos: el docker-compose.yml de la raíz es solo para desarrollo diario y no incluye el relay, que corre en el host. Para un relay de un solo nodo o de VPS hay que usar el bundle de producción de deploy/compose/, que sí incluye el relay como contenedor junto a Postgres, Redis, MinIO y un Caddy opcional para TLS. Esa distinción es el eje de Tu primer relay y de Despliegue en un VPS con Docker Compose.

Para agentes, se define BUZZ_PRIVATE_KEY y se usa buzz-cli: JSON de entrada, JSON de salida, diseñado para llamadas de herramienta de LLM.

Los NIPs que anuncia el relay

Vas a tener que responder “¿qué habla tu relay?” cuando alguien conecte un cliente Nostr de terceros. La respuesta está en el documento NIP-11 que sirve el propio relay, y el listado incondicional es:

SUPPORTED_NIPS = [1, 2, 10, 11, 16, 17, 23, 25, 29, 33, 38, 42, 50, 56]

A eso se agrega condicionalmente NIP-43, y solo cuando se cumplen dos condiciones a la vez: que el relay realmente aplique membresía y que tenga una clave de firma estable. Ambas son necesarias para que los eventos de roster sean verificables por los clientes; anunciar NIP-43 sin clave estable sería mentirle al cliente. La configuración concreta de esas dos condiciones es el tema de Identidad y autenticación.

Un dato que conviene saber desde ya: en el documento NIP-11, el campo auth_required es siempre true, porque los handlers de REQ, EVENT y COUNT rechazan incondicionalmente conexiones que no estén autenticadas. Esto es independiente del toggle REST que se configura por variable de entorno. Buzz no tiene modo anónimo de lectura.

Además, el relay define NIPs propios bajo docs/nips/, todos en estado draft y optional, para cosas que Nostr estándar no cubre: autenticación de agentes, memoria y métricas de agentes, ventana de canal, visibilidad de DMs, firma de objetos git con claves Nostr, archivado de identidades, proyectos multi-repositorio y perfil de workspace, entre otros.

El perfil de quien administra un relay de Buzz

No hace falta ser desarrollador de Rust. Sí hace falta estar cómodo con:

Docker y Docker Compose. El bundle de producción exige Docker Compose v2.24.4 o superior, porque el override de TLS usa el tag !reset.
Postgres. Es la base de datos de eventos: pg_dump, particiones mensuales y migraciones.
Un proxy inverso y TLS. El bundle trae Caddy opcional; con nginx o Traefik, terminar TLS y proxear al 3000 es responsabilidad tuya.
Almacenamiento de objetos compatible con S3. MinIO en el bundle, o el proveedor que uses.
Gestión de secretos. La clave privada de firma del relay es su identidad: rotarla es una identidad nueva, no una rotación transparente.
Kubernetes y Helm, solo por la ruta gestionada. El chart está publicado como artefacto OCI.

Lo que no necesitas: saber Nostr de antes. Los capítulos van a introducir NIP-42, NIP-98 y NIP-34 cuando toque configurarlos, no antes.

Qué vas a saber hacer al terminar

Al final de los catorce capítulos vas a poder, sin ayuda:

Explicar qué crate hace qué y por dónde pasa un evento desde que entra por el WebSocket hasta que queda en Postgres, en el índice de búsqueda y en la cadena de auditoría.
Levantar un relay local desde el código fuente con sus migraciones aplicadas, y escribir un .env de producción entendiendo que el default del binario y el del ejemplo no son el mismo en varias variables de seguridad.
Desplegar un relay de un solo nodo en un VPS con Docker Compose, con TLS y con los puertos internos no expuestos; y el mismo relay en Kubernetes con Helm o en Railway.
Configurar el modo cerrado: exigir membresía, definir el dueño del relay, distinguir NIP-42 de NIP-98 y saber qué hace la allowlist de pubkeys.
Agregar y quitar miembros, asignar roles y operar la cola de moderación.
Conectar un object storage externo con el estilo de direccionamiento correcto, y entender por qué los objetos de git viven ahí.
Diagnosticar por qué una búsqueda no devuelve algo, verificar la cadena de auditoría y servir varias comunidades sobre una misma infraestructura sin filtrar datos entre tenants.
Instrumentar con Prometheus y trazas OTLP, hacer backup consistente y restaurar, actualizar la imagen sin perder la identidad del relay, y ejecutar un runbook bajo presión.

Cómo está organizado el curso

flowchart TD
    c1["1. Que es Buzz"] --> c2["2. Arquitectura del relay"]
    c2 --> c3["3. Primer relay local"]
    c3 --> c4["4. Configuracion por env"]
    c4 --> c5["5. Despliegue en VPS"]
    c4 --> c6["6. Railway y Kubernetes"]
    c5 --> c7["7. Identidad y autenticacion"]
    c6 --> c7
    c7 --> c8["8. Membresia, roles y moderacion"]
    c8 --> c9["9. Medios y almacenamiento"]
    c9 --> c10["10. Busqueda y audit log"]
    c10 --> c11["11. Multi-tenant"]
    c11 --> c12["12. Observabilidad"]
    c12 --> c13["13. Backups y upgrades"]
    c13 --> c14["14. Seguridad y runbook"]

Los capítulos 1 y 2 son conceptuales. Del 3 al 6 se despliega. Del 7 al 11 se configura la política del relay. Del 12 al 14 se opera en producción.

Una nota sobre honestidad técnica

El proyecto es explícito sobre su propio estado y este curso mantiene esa política: lo que el repositorio marca como “en cableado” aparece marcado igual, y lo que no está respaldado por un archivo del repositorio no aparece. Eso incluye reconocer los costos que VISION_SOVEREIGN.md enumera sin adornos: corres infraestructura; la gestión de claves es más dura que “iniciar sesión con Google” porque perder la clave privada significa perder la identidad sin flujo de recuperación; el ecosistema es joven; y la mayoría de tus colaboradores todavía no tiene un par de claves Nostr. Valen la pena si te importa ser dueño de tu proyecto; no valen la pena si buscas el camino de menor resistencia.

Resumen

Buzz es un workspace autohospedable donde humanos y agentes de IA comparten las mismas salas, con el mismo modelo de identidad y el mismo rastro de auditoría; lo que cambia entre unos y otros es el par de claves, no los permisos.
Buzz es un relay Nostr: cada mensaje, reacción, paso de workflow, aprobación de review y evento de git es un evento firmado en un único log. El entero kind es el único switch de despacho, y una feature nueva es un kind nuevo sin cambios rompientes.
Una community es el workspace al que se llega por URL, y la URL es autoritativa: el binding de comunidad ocurre en el paso 0 de la conexión, antes de que ningún handler vea datos de tenant. Un host desconocido se rechaza, nunca cae a un tenant por defecto.
Sobre un solo relay conviven chat, foro, forge git, workflows, búsqueda full-text, media, voz y auditoría: un solo backup, un solo control de acceso, un solo índice de búsqueda.
No es blockchain, no es un plan de reemplazo de humanos y no está terminado. La tabla del README separa lo que funciona hoy de lo que se está cableando: las compuertas de aprobación de workflow y los clientes móviles están en la columna del medio.
Apache 2.0, construido por Block, Inc. El mismo código base OSS sirve para un relay de una comunidad y para un despliegue hospedado de miles.
Tres rutas de adopción: app empaquetada desde los releases de GitHub, relay hospedado en Railway con la plantilla railway.com/deploy/buzz-relay-block cuya definición vive fuera del repositorio, y build desde fuente con Hermit, just setup && just build y just dev.
El docker-compose.yml de la raíz es solo desarrollo y no incluye el relay; para un nodo real se usa el bundle de deploy/compose/.
El perfil del administrador: Docker Compose v2.24.4+, Postgres, proxy inverso con TLS, object storage S3 y gestión de secretos. La clave privada del relay es su identidad: perderla o rotarla es cambiar de identidad.

Siguiente: Arquitectura del relay: crates, datos y pipeline de eventos