Como o Buzz traz patches, CI e review do Git para dentro do chat

Discussão do time no chat, o patch no git, o resultado de CI num terceiro lugar e a decisão de merge perdida em algum comentário que ninguém acha mais

Fala aí, beleza? A Block lançou o Buzz com uma proposta bem específica pra esse vaivém: colocar mensagem, reação, passo de workflow, aprovação de review e evento de git dentro de um único log de eventos assinados criptograficamente 🙂

Neste post eu te conto o que é o NIP-34 (a parte do Nostr que cuida de código), quais eventos existem, o que significa o tal modelo de "branch como sala" e o que ainda pesa contra adotar isso hoje

Formação Recomendada

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

• 120 aulas
• 4 projetos
• 9h 45min

Conhecer formação

O que é o Buzz e por que a Block colocou repositório dentro do chat

O Buzz é um workspace de colaboração criado pela Block, a empresa do Jack Dorsey, lançado em 21 de julho de 2026, onde humanos e agentes de IA trabalham nas mesmas salas

A Block descreve o produto como gratuito e open source, e o código fica no repositório block/buzz sob licença Apache-2.0

O ponto que mais chama atenção não é o chat em si, é o escopo: canais, threads, mensagens diretas, voz, mídia, repositórios de código, canvas, busca, log de auditoria e workflows automatizados no MESMO produto

São dois caminhos pra usar: rodar a sua própria instância na sua infra (self-host) ou criar uma comunidade na hospedagem da Block em buzz.xyz

E o projeto está andando rápido: a 0.5.4 saiu em 3 de agosto de 2026 e a 0.5.5 em 5 de agosto de 2026

Agente com chave própria, não com a sua conta:

Esse detalhe é mais importante do que parece

No Buzz, cada agente de IA recebe o próprio par de chaves criptográficas Nostr, com participação em canais e trilha de auditoria próprias, em vez de operar pela conta de um humano

Se você já rodou bot que posta "como se fosse você", sabe a bagunça que isso vira na hora de auditar quem fez o quê

NIP-34: o que a especificação "git stuff" faz (e o que ela não faz)

Antes do Buzz, vem a especificação

O NIP-34 é a spec do Nostr apelidada de "git stuff", do repositório nostr-protocol/nips, e ela define as formas de colaboração em código sobre Nostr: anúncio de repositório, patches, issues e status

Aí vem a pergunta óbvia: então o Nostr vai hospedar meu código? Não!

Pelo NIP-34, os repositórios continuam hospedados em servidores git

O que o Nostr faz é anunciar a existência do repositório e a disposição do mantenedor de receber patches, relatos de bug e comentários

Ou seja: Nostr é a camada de anúncio e discussão, o git segue sendo o transporte

Se você conhece lista de e-mail com patch (aquele fluxo clássico de kernel), a ideia é próxima disso, só que com evento assinado e distribuído no lugar da caixa de entrada

Como um patch set não se perde:

Duas tags fazem esse trabalho

Eventos de patch devem incluir uma tag a apontando pro endereço do anúncio do repositório (é assim que o patch sabe a qual repo ele pertence)

E patches de um mesmo conjunto devem incluir tag de resposta e (NIP-10) apontando pro patch anterior, encadeando a sequência na ordem certa

Sem isso, um patch set de 5 commits vira 5 eventos soltos, e boa sorte pra montar o quebra-cabeça depois

Os eventos do NIP-34: kinds de patch, pull request, issue e status

No Nostr tudo é evento, e cada tipo de evento tem um número (o kind)

Se liga na tabela de referência:

O ciclo de status:

O status de um patch ou issue começa como Open e é alterado por eventos de status

• 1630: Open
• 1631: Applied/Merged (ou Resolved, no caso de issue)
• 1632: Closed
• 1633: Draft

E aqui tem a regra de leitura que evita muita confusão: o status válido é o evento de status mais recente (por created_at) publicado pelo autor do patch/issue ou por um mantenedor

Ou seja, não é qualquer um da rede que fecha o seu patch, e não adianta ter um evento antigo dizendo Open se veio um 1631 depois

Branch como sala: onde CI, review e merge passam a conviver

Agora a parte que dá nome ao ângulo do post

A documentação do projeto descreve o modelo "branches are channels": ao criar uma feature branch, o Buzz cria um canal onde ficam resultados de CI, comentários de review e a decisão de merge

Ao dar merge, o canal vira registro arquivado

Sacou o que isso resolve? O histórico da decisão passa a morar no mesmo lugar da discussão que gerou a decisão

Não é mais "a gente combinou isso na thread do chat, mas o motivo real tá num comentário do forge que ninguém lembra"

A infra por trás disso:

O relay do Buzz hospeda repositórios git com transporte Smart HTTP padrão

Isso significa git clone e git push comuns, nada de fluxo exótico, mais os manifests NIP-34

O push é assinado pelo npub do usuário, e as operações git assinadas por Nostr são atendidas pelos componentes git-sign-nostr e git-credential-nostr

É o mesmo git que você já usa, com a assinatura amarrando o autor à identidade da rede

Onde isso encaixa no dia a dia: agente, diff no canal e automação

Bora pro concreto

O buzz-cli é a CLI voltada a agentes: JSON na entrada e JSON na saída, stdout só JSON e erros estruturados em stderr, cobrindo mensagens, canais, reações e operações de repo, upload e canvas

Esse contrato existe justamente porque quem chama do outro lado é um agente, não um humano lendo texto colorido no terminal

Um dos comandos manda diff direto pra um canal:

buzz messages send-diff --channel <uuid> --diff - --repo https://github.com/org/repo --commit abc123 < diff.patch

O diff cai no canal onde a discussão já está acontecendo, com repo e commit amarrados

Os códigos de saída (é isso que torna automatizável):

• 0: ok
• 1: erro do usuário
• 2: rede
• 3: autenticação
• 4: outros
• 5: conflito de escrita

Parece detalhe chato, mas é o oposto: sem código de saída distinto, sua automação não sabe se deve tentar de novo (rede) ou parar tudo e chamar alguém (autenticação)

Já me ferrei mais de uma vez tratando tudo como "deu ruim" genérico

Agentes de código e workflows:

O buzz-acp é o harness ACP do Buzz para agentes de código, citando goose, Codex e Claude Code

Se você já anda testando agentes de código no terminal, a lógica é a mesma, só que o agente ganha identidade e canal próprios dentro do workspace

E tem os workflows: YAML por canal, com gatilhos de mensagem, de reação, agendados e webhook, mais um conjunto fixo de ações (send_message, send_dm, set_channel_topic, add_reaction, call_webhook, request_approval e delay)

Dá pra amarrar uma reação num review a um request_approval, ou disparar um call_webhook pra sua infra externa

É a mesma cabeça de quem já monta automação por gatilho e webhook, só que morando dentro do canal onde o time conversa

Vale adotar agora? O que ainda pesa contra

Veredito honesto, sem hype: é cedo

A própria Block descreve a integração de git do Buzz como estágio inicial

E a versão publicada mais recente ser a 0.5.5 reforça o recado: o projeto é novo, tá andando semana a semana

Tem também uma fronteira arquitetural que você precisa saber ANTES de desenhar sua adoção: no arranjo padrão de hoje, a URL do relay seleciona exatamente uma comunidade

Um relay igual a uma comunidade no self-host, e na hospedagem multi-tenant cada comunidade mantém essa mesma fronteira

Se seu plano era um relay servindo várias comunidades independentes, ajuste a expectativa

Pra quem faz sentido experimentar agora:

Time que já opera com agentes de IA e quer auditoria por evento assinado

A arquitetura é um workspace Rust de crates separadas: buzz-core (tipos do protocolo), buzz-relay (WebSocket e REST em Axum), buzz-db (Postgres), buzz-auth (autenticação NIP-42/98 com Schnorr), buzz-pubsub (Redis), buzz-search (busca full-text no Postgres) e buzz-audit (log encadeado por hash)

Dá pra ler cada pedaço e entender exatamente onde seu dado passa, o que é raro nesse tipo de ferramenta

Pra quem tem forge estabelecido, pipeline de CI maduro e nenhuma dor de auditoria, a conta hoje não fecha: espera amadurecer

Próximo passo

O valor aqui não é "chat com git colado do lado", isso já existe faz tempo

O valor é o patch, o status e a decisão de merge virarem eventos assinados no MESMO log da conversa que gerou tudo isso

Próximo passo prático, sem susto:

1. Lê o NIP-34 no repositório nostr-protocol/nips pra entender os kinds e o ciclo de status antes de qualquer coisa
2. Dá uma passada no código em github.com/block/buzz pra ver as crates e o que já existe de verdade
3. Escolhe o caminho: self-host na sua infra ou comunidade na hospedagem em buzz.xyz
4. Testa o fluxo numa branch de baixo risco primeiro, nunca no repo que paga as contas

Só depois disso você decide se move o time

Dá pra sentir o desenho de onde a colaboração com agentes tá indo, mas o "early" que a Block escreveu não é modéstia, é aviso 😀

até o próximo post!