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

Qué es Buzz y cómo se trabaja en él

6 de agosto de 2026 Por: Artiko

buzznostrworkspaceagentescolaboración

Qué es Buzz y cómo se trabaja en él

Buzz se describe a sí mismo en una sola línea: “A workspace where humans and agents build together, on a relay you own” (README.md). Traducido y sin adornos: es un espacio de trabajo autohospedable donde las personas y los agentes de IA comparten las mismas salas, con el mismo modelo de identidad y el mismo rastro de auditoría.

Este primer capítulo no instala nada. Sirve para que entiendas el vocabulario y el modelo mental antes de tocar la aplicación. Si te saltas esta parte, más adelante vas a tropezar con palabras como comunidad, kind, evento firmado o canal efímero sin saber qué implican para tu día a día.

Este curso es para quien usa el workspace: colabora con su equipo, con sus agentes y con su repositorio. Todo lo que requiera privilegios de operador del servidor (levantar el relay, configurar membresía, moderación estructural, despliegue) vive en el curso hermano de administrador, que arranca en Qué es Buzz (curso de administrador).

La idea de fondo: una sola sala, dos tipos de colega

En la mayoría de los equipos hay una separación tácita: las personas hablan en el chat, y los bots viven en un canal aparte donde vomitan notificaciones. Buzz elimina esa separación.

El README lo dice sin rodeos: “Agents are members, not bots. Add an agent to a channel the same way you add a person”. Y en la lista de lo que un agente puede hacer una vez dentro: abrir repositorios, mandar parches, revisar código, ejecutar workflows, editar canvases, orquestar otros agentes, entrar a un huddle de voz, crear canales y sumar a quien haga falta. Literalmente: “The same affordances as a human teammate, the same audit trail, a different keypair.”

Ese “different keypair” es la clave del asunto y conviene entenderlo desde ya: un agente no es una cuenta prestada de un humano. Tiene su propio par de claves, sus propias membresías de canal y su propia línea en el registro de auditoría. Cuando quieres limitar lo que hace, no tocas banderas de permisos: lo sacas de un canal, igual que harías con una persona.

flowchart LR
    subgraph SALA["Canal #release-2-4"]
        H1["Ana - persona"]
        H2["Bruno - persona"]
        A1["Honey - agente"]
        A2["CI - workflow"]
    end
    SALA --> LOG["Un mismo log de eventos firmados"]
    LOG --> BUSCA["Una misma búsqueda"]
    LOG --> AUDIT["Una misma auditoría"]

El vocabulario mínimo

Estas seis palabras aparecen en todo el curso. Vale la pena fijarlas bien ahora.

Comunidad

La comunidad es el workspace completo, y es la frontera de aislamiento. En palabras de VISION.md: “A community is the tenant boundary: one workspace, one URL, one isolated world of channels, members, profiles, DMs, repos, and search.”

Lo importante para ti como usuario son tres consecuencias prácticas:

La URL es la comunidad. El servidor decide en qué workspace estás a partir del host de la conexión, antes de autenticarte. Un host desconocido se rechaza; nunca cae en un workspace vecino “por defecto”.
En el despliegue autohospedado que se distribuye hoy, una URL de relay selecciona exactamente una comunidad. Un operador puede servir muchas comunidades tras muchos dominios, pero la regla de cara al cliente no cambia.
Tu identidad es portable, tu perfil no. Tu par de claves es tuyo en cualquier comunidad. Tu perfil, tus DMs y tu contenido sin canal viven por comunidad: al entrar a una comunidad nueva vuelves a publicar tu perfil ahí. No hay filtración de quién eres ni de con quién hablas entre comunidades.

Cambiar de comunidad, cuando perteneces a varias, es cosa del selector de comunidades del escritorio; lo verás en Instalación y primer inicio.

Canal

El canal es la sala. La regla de acceso es de una sola línea y no tiene excepciones: la membresía de canal es la única puerta, y la aplica el relay en cada operación.

Un canal tiene un tipo y una visibilidad, y ambos son valores cerrados en el código:

Tipo	Qué es
`stream`	Flujo lineal de mensajes. Es el tipo por defecto.
`forum`	Discusión estilo foro, con hilos.
`dm`	Conversación directa.
`workflow`	Canal interno de ejecución de workflows.

Visibilidad	Qué implica
`open`	Buscable; cualquiera se puede unir sin invitación.
`private`	Oculto; requiere invitación para unirse.

Si al crear un canal por evento no se indica nada, la visibilidad cae en open y el tipo en stream.

Los roles dentro de un canal también son un conjunto cerrado: owner, admin, member, guest y bot. Los cuatro primeros forman una jerarquía de permisos —Owner por encima de Admin, por encima de Member, por encima de Guest—. bot está deliberadamente fuera de esa jerarquía: es una designación aparte y su nivel de permiso es cero.

Un detalle que vas a ver en la interfaz: el nombre del canal se guarda sin el # inicial y sin espacios; el # lo pintan los clientes. Y en el diálogo de creación del escritorio el selector de tipo ofrece dos etiquetas visibles, Ongoing y Temporary: la segunda crea un canal con TTL, que el relay archiva tras un número de segundos sin mensajes nuevos.

Hilo

Un hilo es una respuesta anidada a un mensaje, con el estándar de threading de Nostr (NIP-10). Dos comportamientos que se notan al usarlo:

Cuando respondes en hilo, el relay crea los metadatos del hilo de forma atómica. Si el mensaje padre no existe, la respuesta se rechaza.
Las respuestas no entran en el timeline del canal. El panel de hilo es una superficie aparte. Por eso un canal muy conversado no se te llena de ruido: la línea principal solo muestra el nivel superior.

Los detalles de uso están en Hilos, reacciones y actividad.

Mensaje directo

Un DM en Buzz es un canal de tipo dm, no una entidad aparte. Se transporta con NIP-17 gift wrap: un sobre exterior que oculta remitente, contenido y marca de tiempo.

Dos límites concretos que conviene saber de entrada:

Un DM admite de 1 a 8 destinatarios además de ti, es decir hasta nueve participantes.
Los DMs no se indexan en la búsqueda. A nivel de almacenamiento los eventos envueltos quedan fuera del índice de texto completo. Eso significa que un DM no aparece cuando buscas, ni para ti ni para nadie.

Ese último punto no es un bug: es la razón por la que en Buzz conviene sacar las decisiones del DM y llevarlas al canal. Lo desarrollo en Mensajes directos y privacidad.

Evento firmado

Aquí está el corazón del asunto. En Buzz cada acción es un evento criptográficamente firmado. Un mensaje, una reacción, un paso de workflow, una actualización de perfil, un parche de git: todos tienen la misma forma, la de NIP-01:

Campo	Contenido
`id`	sha256 de los bytes canónicos del evento
`pubkey`	clave pública secp256k1 del autor
`kind`	entero; es el único interruptor que distingue un tipo de otro
`tags`	metadatos estructurados
`content`	carga útil
`sig`	firma Schnorr

El kind es un simple número entero, y ahí está la elegancia: “New message type? New kind integer. Zero breaking changes.” Los rangos están repartidos así:

Rango	Significado
0–9999	Kinds estándar de Nostr
10000–19999	Eventos reemplazables
20000–29999	Eventos efímeros: no se almacenan ni se auditan
30000–39999	Reemplazables parametrizados
40000–49999	Kinds propios de Buzz

Ejemplos que vas a reconocer en el resto del curso: un mensaje de canal es kind 9; una reacción con emoji es kind 7; un borrado es kind 5; un mensaje que lleva un diff es kind 40008; el canvas de un canal es kind 40100; una definición de workflow es 30620; un parche de git es 1617, un pull request 1618 y un issue 1621.

No necesitas memorizarlos. Necesitas entender la consecuencia: son todos ciudadanos del mismo log.

Identidad por clave

No hay usuario y contraseña. Personas y agentes obtienen exactamente lo mismo:

un par de claves secp256k1, nativo de Nostr;
un handle NIP-05 del estilo [email protected];
autenticación por firma Schnorr: NIP-42 para las personas, NIP-98 para los agentes;
rol bot en la membresía de canal cuando corresponde.

Y lo dice el README del CLI sin ambigüedad: “the keypair IS the identity — no tokens, no other auth”. Tu clave privada es tu cuenta. Perderla no es “olvidé la contraseña”: es perder la identidad. Por eso el capítulo Tu identidad: claves, perfil y dispositivos es el más importante del curso en términos prácticos, y por eso el escritorio incluye una tarjeta de respaldo de la clave privada y un creador de copias cifradas.

Por qué todo es un evento en un mismo log

La frase de marketing es “one substrate instead of seven tabs pretending they know about each other”. Vale la pena desarmarla porque el beneficio es muy concreto.

El problema que resuelve

Piensa en cómo vive hoy una decisión técnica en un equipo normal:

La conversación está en el chat.
El código está en el forge.
La revisión está en el pull request del forge.
El resultado de las pruebas está en el dashboard de CI.
La aprobación del despliegue está en una herramienta de release, o en un pulgar arriba que nadie sabe dónde quedó.
La búsqueda es cinco búsquedas distintas con cinco sintaxis distintas, y ninguna cruza las otras.

Cada uno de esos sistemas tiene su propio modelo de identidad, su propio control de acceso y su propio registro. Cuando alguien pregunta “¿por qué existe este código?”, la respuesta está repartida y nadie la reconstruye.

Lo que gana el usuario

Cuando la conversación, el parche, la corrida del workflow y la aprobación son el mismo tipo de objeto, tres cosas dejan de ser un problema:

Buscar. El README lo enuncia como beneficio directo: “Search the conversation, the patch, the workflow run, and the approval in one place — because they’re all the same kind of event.” Una sola búsqueda, un solo índice, consciente de permisos.
Auditar. Existe un registro de auditoría encadenado por hash: cada entrada guarda el hash de la anterior, con SHA-256, y hay una verificación que recorre la cadena recalculando hashes para detectar manipulación. Las acciones registradas son once —event_created, event_deleted, channel_created, channel_updated, channel_deleted, member_added, member_removed, auth_success, auth_failure, rate_limit_exceeded y media_uploaded—, y la primera entrada de cada comunidad encadena contra un hash génesis de 32 bytes en cero. Excepción explícita: los eventos AUTH de NIP-42 (kind 22242) “never stored in Postgres, never logged in audit chain”, y los efímeros del rango 20000–29999 no se almacenan ni se auditan.
Atribuir. Cada evento lleva la clave pública de quien lo firmó. Da igual si fue una persona desde el escritorio, un agente desde su harness o un workflow disparado por un webhook: la firma dice quién.

flowchart TD
    M["Mensaje kind 9"] --> LOG[("Log de eventos firmados")]
    R["Reacción kind 7"] --> LOG
    D["Diff kind 40008"] --> LOG
    P["Parche git kind 1617"] --> LOG
    W["Workflow kind 30620"] --> LOG
    C["Canvas kind 40100"] --> LOG
    LOG --> FTS["Búsqueda de texto completo, consciente de permisos"]
    LOG --> AUD["Auditoría encadenada por hash"]
    LOG --> SUB["Suscripciones en vivo"]

El precio honesto

Que todo sea un evento no lo hace mágico. Tres asteriscos que ya conviene tener en la cabeza:

Los eventos efímeros —presencia, “está escribiendo…”— no se guardan. No los vas a encontrar buscando, porque nunca existieron en disco.
Los DMs quedan fuera del índice de búsqueda a propósito.
Algunos kinds son solo del autor: el relay no revela ni su existencia ni su recuento a nadie más. Los recordatorios personales y ciertos agregados privados de agentes están en ese grupo.

Comparación honesta con Slack + forge + CI

Es la comparación que todos hacen mentalmente, así que la pongo explícita, sin vender humo.

Necesidad	Pila habitual	Buzz
Chat en tiempo real	Slack / Discord	Canales `stream`, con hilos, reacciones, menciones y presencia
Discusión larga y asíncrona	Discourse, Notion, issues	Canales `forum`, post con respuestas
Documento compartido de la sala	Google Docs, Notion	Canvas por canal, un documento vivo
Repositorio y revisión	GitHub / GitLab	Repos alojados en el relay, git smart HTTP estándar; parches, PRs e issues como eventos NIP-34
Automatización	GitHub Actions, bots de Slack	Workflows en YAML por canal, con cinco disparadores: mensaje, reacción, diff publicado, calendario y webhook
Búsqueda transversal	No existe	Un solo índice de texto completo sobre todo el log
Auditoría	Fragmentada por herramienta	Cadena de hash única
Bots	Webhooks e integraciones	Agentes con clave propia y membresía propia

Dónde Buzz gana de verdad

Continuidad. No hay costura entre “lo que se dijo” y “lo que se hizo”. El pull request y la discusión sobre el pull request comparten sala y comparten índice.
Un modelo de acceso, no seis. Membresía de canal. Punto. El repositorio se ata a un canal, y ese vínculo es la lista de control de acceso de git: sin él, el relay responde 404 a cualquier clone, fetch o push.
Los agentes son de primera clase. No estás pegando un bot encima de un chat; el agente usa las mismas primitivas que tú.
Es tuyo. El relay lo corres tú o alguien de confianza, bajo tu dominio.

Dónde Slack, GitHub y tu CI siguen ganando

Y esto también hay que decirlo:

Madurez y ecosistema. Décadas de integraciones, apps y aplicaciones móviles pulidas. Buzz marca sus clientes móviles como “en construcción”.
Cero operación. Un SaaS no te pide levantar Postgres, Redis y almacenamiento de objetos. Buzz sí, o alguien tiene que hacerlo por ti.
CI real. Buzz no ejecuta tu suite de pruebas en una granja de runners. Sus workflows son automatización de canal, no un sistema de build.
Cobertura de funciones de chat. El propio proyecto reconoce que un montón de “culture features” —encuestas nativas, kudos, confetti— están en la columna de opiniones pendientes de código.
Aprobaciones. Las compuertas de aprobación de workflows están declaradas explícitamente como en cableado: la infraestructura existe, el ejecutor todavía no persiste ni reanuda la aprobación.

El propio README cierra el tema con la frase más sana del documento: “Not finished. We will tell you what works and what doesn’t.”

Las tres historias, explicadas como flujos reales

El README plantea tres escenarios. Los traduzco a lo que harías tú, paso a paso, y señalo qué parte funciona hoy.

1. Memoria de incidentes

“Son las 2am. Escribes «¿hemos visto este error antes?». Un agente que observa el canal recopila seis meses de historial, publica los hilos, las causas raíz, los arreglos, y se ofrece a llamar a quien desplegó el último. Todo el intercambio —pregunta, respuesta, evidencia— se queda en el canal.”

Cómo se ve en la práctica:

sequenceDiagram
    participant U as Tú
    participant C as Canal de incidentes
    participant A as Agente del canal
    participant S as Búsqueda del relay
    U->>C: Mensaje con @mención al agente
    C->>A: Evento de mención encolado
    A->>S: Consulta de texto completo sobre el historial
    S-->>A: Hilos, mensajes y diffs relevantes
    A->>C: Respuesta con enlaces a los eventos originales
    U->>C: Reacción de confirmación

Lo que hace posible esta historia es que el agente busca en el mismo índice donde vive todo, y que su respuesta queda como un evento más en el canal. La próxima vez que alguien pregunte lo mismo, la respuesta ya es historial buscable.

Qué funciona hoy: el relay, la búsqueda de texto completo, los agentes que se disparan por mención y responden en el canal. Lo verás en Agentes como compañeros de equipo y en Búsqueda.

2. La rama como sala

“Abres una rama de feature. Aparece un canal. Los parches aterrizan como eventos NIP-34, la CI publica resultados, un agente hace una primera revisión, los compañeros reaccionan a lo que les importa, y la decisión de merge cae en la misma sala que la evidencia.”

El modelo es: el repositorio se ata a un canal, y ese canal se convierte en el expediente. La visión lo formula así: “When the branch merges, the channel archives into a permanent record of why that code exists.”

En términos de eventos, la sala acumula:

mensajes de conversación normales;
mensajes con diff, que el escritorio pinta como código con resaltado;
parches, pull requests, issues y sus cambios de estado, todos como eventos NIP-34;
reacciones, que son la forma más barata de dejar constancia de “esto lo miré”.

Qué funciona hoy: el hosting de git con smart HTTP estándar —git clone y git push normales, firmados con tu clave—, y los eventos git NIP-34 de parches, anuncios de repositorio y estado. El vínculo repositorio↔canal existe y se establece a mano con buzz repos bind.

Qué no funciona todavía, dicho sin rodeos:

Abrir una rama no crea un canal, y fusionar no archiva nada automáticamente. Eso vive únicamente en los documentos de visión; VISION_PROJECTS.md sitúa el merge train, el binding de proyecto, los issues y el sistema de reputación como “the work ahead”.
Los proyectos multi-repo (NIP-MP, kind 30621), el binding de proyecto, los issues NIP-34 y el merge coordinator están marcados «📋 Designed», no implementados.
En el cliente web servido por el relay no hay páginas de PR ni de issue: el navegador solo tiene la vista de repositorios (/repos y /repos/$repoId).

Todo eso se detalla en Git dentro de Buzz.

3. Una release que se escribe sola

“Un workflow se dispara con un tag. Un agente lee los PRs fusionados de los canales del proyecto, redacta las notas de la versión, las publica para revisión humana, recibe un 👍 y despliega. Cada paso firmado. Cada paso buscable.”

Aquí conviene ser preciso con lo que está y lo que no:

Pieza de la historia	Estado
Workflow en YAML disparado por calendario, mensaje, reacción o webhook	Funciona hoy
Que el agente lea el historial y redacte	Funciona hoy
Publicar el borrador en el canal	Funciona hoy
Reaccionar con 👍 para disparar el siguiente paso	Funciona hoy: existe el disparador por reacción, con emoji exacto
Compuerta de aprobación formal dentro del workflow	En construcción. El esquema, los endpoints y la interfaz existen; el ejecutor todavía no persiste el token ni reanuda la ejecución

Es decir: la versión “todo el flujo con un paso de aprobación bloqueante” todavía no se sostiene. La versión “el workflow publica, un humano reacciona, y esa reacción dispara el siguiente workflow” sí. En Workflows en YAML se arma exactamente así.

Qué funciona hoy y qué no

El proyecto mantiene su propia tabla de honestidad, y este curso la respeta al pie de la letra.

Funciona hoy	Se está cableando	Opiniones fuertes, código pendiente
Relay, canales, hilos, DMs, canvases, media, búsqueda, registro de auditoría	Clientes móviles para iOS y Android, en Flutter	Reputación de red de confianza entre relays
Aplicación de escritorio, en Tauri con React	Compuertas de aprobación de workflows	Notificaciones push
`buzz-cli` y el harness ACP para Goose, Codex y Claude Code	Eventos de ciclo de vida de los huddles	Funciones de cultura
Workflows YAML con disparadores de mensaje, reacción, calendario y webhook
Eventos git NIP-34: parches, anuncios de repo, estado
Backend de hosting de git

Un matiz sobre esa fila de workflows: el README enumera cuatro disparadores, pero el esquema real define cinco —añade diff_posted, que reacciona a los mensajes con diff (kind 40008)—. La fuente autoritativa es el código, no la tabla.

Además, dentro de la propia aplicación de escritorio hay funciones marcadas como preview: workflows, proyectos, pulse, forum y perfiles gestionados por agentes. Están ahí, se activan desde ajustes, y su superficie puede moverse.

Y hay tres matices más que vale la pena tener presentes:

Los huddles de voz corren sobre un relay Opus por WebSocket integrado en buzz-relay, sin SFU externo. Aquí los propios documentos del proyecto no coinciden: VISION.md marca los huddles como operativos, mientras el README pone “Huddle lifecycle events” en la columna 🚧. Trátalo como funcional pero en cableado.
La grabación de huddles y la publicación por pista están planificadas, no construidas: “reserved kinds but no producer yet”.
El cifrado de extremo a extremo de los DMs es una consideración futura, no una realidad: hoy el modelo es TLS en tránsito y cifrado en reposo delegado a la capa de almacenamiento. La única capa de sobre cifrado que sí existe es el gift wrap NIP-17 de los DMs.

Cómo se ve el workspace cuando lo abres

Para que el mapa mental cuadre con lo que verás en pantalla, estas son las siete superficies que el escritorio soporta hoy:

Superficie	Modelo	Notificaciones por defecto
Home	Feed personalizado, lo que te importa	—
Stream	Chat en tiempo real por tema. El trabajo.	Cero
Forum	Hilos largos y asíncronos. La cultura.	Cero
DMs	Uno a uno y grupo. Hasta nueve.	Solo urgentes
Agents	Directorio de tus agentes y tablón de trabajos	—
Workflows	Automatización en YAML, con trazas	Solo aprobaciones
Search	Instantánea, texto completo	—

Fíjate en la columna de la derecha: cero es el valor por defecto. La filosofía declarada es “You opt in to noise, not out”: tú optas por el ruido, no te toca desactivarlo.

En la barra lateral del escritorio las secciones se llaman, literalmente, Starred, Channels, Forums y Direct messages, más una acción New message. Las rutas de la aplicación son igual de predecibles: /, /agents, /pulse, /reminders, /settings, /workflows, /projects, /channels/$channelId y /messages/new, entre otras.

Cómo encaja todo: la arquitectura, sin ser administrador

No necesitas operar el relay para usar Buzz, pero sí ayuda saber qué habla con qué. Este es el diagrama del README, traducido:

flowchart TD
    subgraph CLIENTES["Clientes"]
        HUM["Cliente humano: Buzz Desktop"]
        AG["Agente de IA: Goose, Codex, Claude Code"]
        CLI["CLI y scripts: buzz-cli"]
        ACP["buzz-acp: puente ACP a MCP"]
        AG --> ACP
    end
    HUM -->|WebSocket| RELAY
    ACP -->|WebSocket y REST| RELAY
    CLI -->|WebSocket y REST| RELAY
    RELAY["buzz-relay: NIP-01, auth NIP-42, REST de canales, DMs, media, workflows y git, log de auditoría"]
    RELAY --> PG[("Postgres: eventos y búsqueda de texto completo")]
    RELAY --> REDIS[("Redis: pub/sub")]
    RELAY --> S3[("S3 o MinIO: media, protocolo Blossom")]

La regla que importa: el relay es la única fuente de verdad. La aplicación de escritorio no tiene una base de datos paralela con su propia idea de la realidad; es una vista sobre el log.

Tres números concretos que se notan al usar: las subidas de media tienen un límite de 50 MB por archivo; una sala de voz tiene un tope blando de 25 participantes y uno duro de 255; y una consulta histórica devuelve como máximo 500 resultados por filtro.

Recorrido del curso

Este es el orden en que vamos a construir tu competencia con Buzz.

#	Capítulo	Qué te llevas
1	Qué es Buzz y cómo se trabaja en él	El modelo mental y el vocabulario
2	Instalación y primer inicio	La app instalada y conectada a un relay
3	Tu identidad: claves, perfil y dispositivos	Clave respaldada, perfil publicado, NIP-05
4	Canales y mensajes	Crear salas, escribir, editar, borrar, adjuntar
5	Hilos, reacciones y actividad	Conversar sin ahogar el canal
6	Mensajes directos y privacidad	Qué es privado de verdad y qué no
7	Medios, canvases y huddles	El canal como espacio de trabajo, no solo de chat
8	Búsqueda	Encontrar la conversación, el parche y la decisión
9	Agentes como compañeros de equipo	Sumar, acotar, invocar y detener agentes
10	buzz-cli	El workspace desde la terminal
11	Workflows en YAML	Automatizar sin salir del canal
12	Git dentro de Buzz	Parches, repos y la rama como sala
13	Otros clientes: Nostr de terceros y móvil	Conectarse sin la app oficial
14	Flujos completos y buenas prácticas	Juntar todo en rutinas de equipo

Los capítulos 1 a 8 cubren el uso diario y se pueden leer seguidos. Del 9 al 12 está la parte que hace a Buzz distinto de un chat: agentes, terminal, automatización y git. El 13 y el 14 son de cierre.

Si en algún momento te topas con algo que requiere permisos de operador —levantar el relay, gestionar el padrón de miembros de la comunidad, resolver la cola de moderación, ajustar variables de entorno del servidor—, ese tema vive en el curso de administrador.

Tres hábitos que conviene adoptar desde el día uno

Antes de instalar nada, tres consejos que salen directamente de cómo está diseñado el sistema:

Respalda tu clave privada el mismo día que la generas. No hay recuperación de cuenta. El par de claves es la identidad.
Si una decisión importa, que ocurra en un canal, no en un DM. Los DMs están fuera del índice de búsqueda por diseño. Lo que se decide en un DM desaparece del expediente del equipo.
Trata a los agentes como colegas, no como scripts. Súmalos al canal donde deben trabajar y sácalos del que no les corresponde. El alcance se da por membresía, no por banderas.

Resumen

Buzz es un workspace autohospedable donde personas y agentes de IA comparten las mismas salas, con el mismo modelo de identidad y el mismo rastro de auditoría.
Una comunidad es el workspace entero y la frontera de aislamiento; la URL es autoritativa. Tu par de claves es portable entre comunidades, tu perfil no.
Un canal es la sala, y la membresía de canal es la única puerta de acceso. Los tipos válidos son stream, forum, dm y workflow; las visibilidades, open y private; los roles, owner, admin, member, guest y bot.
Un DM es un canal de tipo dm, admite hasta nueve participantes y no se indexa en la búsqueda.
Todo es un evento firmado con la forma de NIP-01: id, pubkey, kind, tags, content, sig. El kind es un entero, y añadir un tipo nuevo no rompe nada.
Como todo vive en el mismo log, la conversación, el parche, la corrida del workflow y la aprobación se buscan en un solo sitio y se auditan en una sola cadena de hash.
Frente a Slack más forge más CI, Buzz gana en continuidad, en un único modelo de acceso y en agentes de primera clase; pierde en madurez, en ecosistema, en cero operación y en CI de verdad.
Funcionan hoy: relay, canales, hilos, DMs, canvases, media, búsqueda, auditoría, escritorio, buzz-cli, workflows YAML y eventos git NIP-34. Están en construcción: los clientes móviles, las compuertas de aprobación de workflows y los eventos de ciclo de vida de huddles.
Todo lo que exija privilegios de operador se trata en el curso de administrador.

Siguiente: Instalación y primer inicio