O que é o Buzz do Block e como funciona o log único de eventos assinados?

Fala aí, beleza? Quando um time coloca agentes de IA pra trabalhar junto, o rastro do que aconteceu se espalha: um pedaço no chat, outro no repositório, outro na ferramenta de review

Aí você tenta reconstruir quem fez o quê e vira arqueologia

O Buzz é a tentativa do Block de resolver isso pela raiz: em vez de três sistemas conversando por link, tudo vira evento assinado dentro de um log único

Neste post eu explico a ideia central e como as peças se encaixam

De onde veio o Buzz e por que o Block lançou

O Buzz foi lançado publicamente pelo Block em 21 de julho de 2026, com anúncio de Jack Dorsey, como consta no anúncio oficial no site do Block

Formação Recomendada

Formação Agentes de IA

Domine a criação de Agentes de IA e Venda para Empresas

• 402 aulas
• 32 projetos
• 38h 19min

Conhecer formação

A descrição é direta: uma plataforma de group chat para times formados por pessoas E agentes, com a intenção de reduzir a dependência de Slack e GitHub

O próprio Block chama isso de "hive mind": um lugar só onde humano e agente compartilham os mesmos canais

E não é caixa preta, se liga: o código está publicado no repositório block/buzz sob licença Apache-2.0, com cerca de 24,5 mil estrelas no GitHub

O workspace é auto-hospedável

Quem não quer administrar nada usa o buzz.xyz, que serve pra criar e gerenciar comunidades hospedadas pelo próprio Block

Quem prefere rodar por conta própria sobe o próprio relay

Como funciona o log único de eventos assinados

Aqui mora o coração da coisa

O Buzz é construído sobre o Nostr, um protocolo aberto baseado em eventos assinados e pares de chaves criptográficas

"Par de chaves?" É o mesmo conceito que você já usa quando gera uma chave SSH pra falar com o Git: uma chave privada que fica com você e assina, uma pública que qualquer um usa pra conferir a assinatura

No Buzz, cada pessoa e cada agente tem um keypair próprio, independente de conta gerenciada por fornecedor

Isso deixa a identidade portátil e verificável, e não presa a um login de plataforma

Na parte de protocolo, o Buzz implementa eventos NIP-01 e autenticação NIP-42, além de kinds de evento customizados pra canais, threads, DMs, mídia e workflows

Ou seja: canal, thread, DM e etapa de workflow não são "telas" diferentes com bancos diferentes, são tipos de evento no mesmo formato

E o git? Essa é a parte que eu acho MUITO massa

Eventos de git no Buzz seguem o NIP-34, então patch, anúncio de repositório e atualização de status são eventos assinados de primeira classe

Não é um link pra um sistema externo, é o evento em si vivendo no mesmo log da conversa

Fecha com o buzz-audit, o serviço que grava um log de auditoria à prova de adulteração

Cada entrada é encadeada à anterior por hash SHA-256

Se alguém mexer numa entrada do meio, a corrente quebra e a adulteração aparece

Por que isso importa mais do que parece:

Mensagem, reação, etapa de workflow, aprovação de review e evento git compartilham o mesmo formato, o mesmo modelo de identidade e a mesma trilha de auditoria

Seja o autor uma pessoa ou um processo

É essa frase que resume o produto inteiro

As peças do Buzz: o que cada serviço faz

A arquitetura separa responsabilidades em serviços, o que ajuda bastante a entender o que é o quê quando você abre o repositório pela primeira vez

Sobre o buzz-acp, vale detalhar: ele escuta menções no relay, aciona o agente e permite que o agente responda pela CLI do Buzz

Funciona com qualquer agente que fale ACP por stdio

Já o forge git embutido é o que permite hospedar repositório e conduzir review sem um code host separado

Do lado da stack, o backend é escrito em Rust e os clientes em TypeScript/React

O cliente desktop é um app Tauri 2 com React 19, disponível pra macOS, Windows e Linux

E o próprio relay também serve um cliente web de navegador, então dá pra abrir sem instalar nada

O que o log único muda na rastreabilidade de um time com agentes

Traduzindo a arquitetura pra vida real

Quando tudo é evento assinado no mesmo log, a pergunta "quem fez isso?" tem UMA resposta, no mesmo formato, não importa se quem agiu foi uma pessoa ou um processo

O review aprovado e o patch enviado moram na mesma trilha de auditoria que a mensagem no canal

Mas tem um detalhe que muda tudo quando entra agente no meio

Agente no Buzz precisa de par de chaves Nostr próprio e herda acesso do dono humano via NIP-OA, a owner attestation

Esse mecanismo prova qual humano autorizou qual agente

Sacou a diferença? Não é o agente usando o crachá do dono

É o agente com crachá próprio, mais um documento assinado dizendo quem o autorizou

E o contraponto honesto:

O próprio README do Buzz pede que ninguém planeje seu programa de compliance em cima da coluna de itens que ainda não foram entregues

E os portões de aprovação humana ainda estão sendo conectados

Isso vem do projeto, não de mim, e é um recado que eu acho MUITO saudável de encontrar num README

Tome cuidado se a sua leitura foi "achei minha trilha de auditoria pronta pra auditoria formal": ainda não é essa a promessa

Para quem o Buzz faz sentido hoje

O README lista como funcionando hoje: relay, canais, threads, DMs, canvases, mídia, busca, log de auditoria, app desktop, buzz-cli, workflows em YAML, eventos git (NIP-34) e hospedagem git

Em cima disso, dá pra desenhar alguns cenários

• Time que quer chat e repositório no mesmo lugar: com o forge git embutido e eventos git de primeira classe, o code host separado deixa de ser obrigatório
• Time que já roda agentes por ACP: se você usa Goose, Codex ou Claude Code, o buzz-acp pluga eles no canal e o NIP-OA deixa registrado quem autorizou cada um
• Quem quer soberania da própria infra: o workspace é auto-hospedável e você sobe o seu relay, sem depender da hospedagem do Block
• Quem quer só experimentar: app desktop pra macOS, Windows e Linux, ou o cliente web servido pelo próprio relay

E o caso em que ainda NÃO faz sentido? Se o seu processo depende de aprovação humana formalizada, com portão de verdade barrando a ação do agente

Essa parte ainda está sendo conectada, então não vale apostar o processo do time nela agora

Vale acompanhar o Buzz?

Vale, e por um motivo bem específico

O que diferencia o Buzz não é ser "mais um chat com IA"

É a ideia central: tudo é evento assinado no mesmo log, e identidade é par de chaves, não conta de fornecedor

Isso resolve um problema que hoje a maioria dos times resolve na base do print e da memória, que é reconstruir o rastro de uma decisão tomada entre humano e agente

A maturidade, por outro lado, é declarada pelo próprio projeto, e isso conta a favor da honestidade dele

Meu próximo passo sugerido pra você: abre o github.com/block/buzz, lê o README com calma, roda o app desktop ou sobe um relay próprio pra sentir o fluxo

Depois disso você decide se coloca processo de time em cima, e não antes

Bora testar? 😀

até o próximo post!