A tese do projeto

O Buzz parte de uma frase simples: o relay é o workspace. Conversas, agentes, workflows, artefatos, mídia, Git e memória devem viver atrás de um domínio, de uma identidade e de um log comum. O agente não é um bot escondido atrás de uma integração; ele é um membro com chave própria, presença, canais, histórico e trilha de auditoria.

Debaixo da interface de equipe há um relay Nostr. Cada mensagem, reação, mudança de canal, passo de workflow e evento de Git é um evento assinado, identificado por um kind. O mesmo formato e a mesma identidade servem para a pessoa e para o processo.

Arquitetura real

Desktop / Web / Mobile / buzz-cli / agentes ACP
                    ↓ WebSocket + REST
              buzz-relay (Rust + Axum)
        ┌───────────┼───────────┬───────────┐
     Postgres     Redis       S3/MinIO    crates
  eventos/FTS   pub/sub      mídia/Git   auth/audit/workflow

O relay é a fonte única de verdade. Ele autentica, verifica assinatura, valida membership, persiste, distribui aos inscritos, indexa, audita e dispara workflows. Os crates são separados: buzz-core define eventos e filtros; buzz-auth cuida de NIP-42/NIP-98; buzz-db persiste; buzz-pubsub usa Redis; buzz-search usa full-text do Postgres; buzz-audit encadeia hashes; buzz-workflow executa automações.

Isso produz uma escolha arquitetural forte: uma funcionalidade nova não precisa criar mais uma API isolada. Em princípio, define um novo kind, passa pelo pipeline já autenticado e ganha fan-out, histórico, busca e auditoria.

Identidade: humanos e agentes no mesmo plano

WebSocket usa NIP-42: o relay envia um desafio e o cliente responde com um evento assinado, provando posse da chave. A ponte HTTP usa NIP-98, com assinatura que cobre URL e método. O acesso ao conteúdo não termina na autenticação: membership de canal é o portão real. Estar autenticado não significa poder ler todos os canais.

Há papéis de owner, admin, member, guest e bot. Agentes recebem sua própria chave Nostr, podem pertencer a canais e podem ser localizados como participantes da comunidade. O desktop guarda chaves no keyring do sistema; em Linux sem Secret Service, recorre a arquivo com permissão de proprietário. A perda da chave continua sendo uma perda real de identidade — não há “esqueci minha senha” tradicional.

Em multi-community, o host da requisição determina a comunidade antes de AUTH, EVENT, REQ, REST, mídia, Git ou workflows. A ideia é que projeto-a.example e projeto-b.example possam compartilhar infraestrutura sem compartilhar estado observável. O código e a documentação tratam esse limite como uma propriedade de segurança, não apenas como um filtro de interface.

O agente deixa de ser um processo anônimo

O buzz-cli é a superfície agent-first: JSON na entrada e na saída, erros estruturados e comandos para mensagens, canais, threads, busca, canvas, mídia, workflows, Git, memória e administração. Isso é importante porque o agente não precisa dirigir a UI para participar do trabalho.

O buzz-acp faz a ponte entre o relay e agentes ACP como Goose, Codex e Claude Code. Ele ouve menções, descobre canais acessíveis, agrupa eventos por canal, envia um prompt por ACP e publica a resposta usando o CLI. Há pool de 1 a 32 subprocessos, uma execução simultânea por canal, recuperação de processo e filtro de autores. O default é owner-only, uma escolha sensata para evitar que qualquer membro transforme um agente em caixa de execução pública.

O par buzz-agent + buzz-dev-mcp segue uma filosofia mais minimalista: ACP de um lado, MCP do outro, cada sessão com seus próprios servidores MCP. O servidor de desenvolvimento oferece shell, leitura, edição, rg, árvore e tarefas; opera no nível de confiança do usuário, portanto não é uma sandbox mágica. A segurança está em limites de processo, saída, tempo, cancelamento e no ambiente em que o binário é executado.

O workspace é mais que chat

A ambição é substituir o mosaico “chat + GitHub + CI + bot + wiki + busca” por um substrato comum. Não porque cada peça isolada seja nova, mas porque a pergunta, o patch, a aprovação e a decisão de merge passam a ser eventos pesquisáveis no mesmo lugar.

Workflows: coordenação com evidência

Workflows são YAML-as-code. Podem disparar por mensagem, reação, agenda ou webhook. As ações incluem enviar mensagem, reagir, chamar webhook, atrasar e solicitar aprovação. Condições usam evalexpr, têm funções de string e timeout curto; webhooks têm proteção contra SSRF, redirects desabilitados e limite de resposta.

A promessa é boa: uma automação não só executa, mas deixa uma trilha de passos. Porém existe um limite concreto no commit analisado: send_dm e set_channel_topic ainda retornam NotImplemented; gates de aprovação têm schema, APIs e UI, mas o executor ainda marca o run como falho em vez de persistir e retomar a aprovação.

Esse detalhe importa. Uma interface de aprovação não equivale ainda a uma barreira de aprovação. Para governança real, o caminho completo precisa parar, guardar o token com segurança, esperar a decisão e retomar o mesmo run.

Auditoria e privacidade

O audit log usa uma cadeia SHA-256: cada entrada aponta para o hash anterior, por comunidade. Isso detecta corrupção e edição isolada. O próprio projeto é honesto sobre a limitação: como a cadeia não é assinada por uma autoridade externa, quem possui acesso de escrita ao banco pode reescrever toda a cadeia. É tamper-evident, não tamper-proof.

Também não há criptografia ponta a ponta como promessa atual. TLS protege o trânsito; a criptografia em repouso é delegada ao Postgres, aos volumes e ao storage operado. Isso favorece busca, eDiscovery e auditoria pelo servidor, mas significa que o relay é capaz de ler o conteúdo.

Há outro achado de arqueologia: o documento de arquitetura ainda descreve a ausência de rate limiting Redis-backed, enquanto o código atual já possui RedisRateLimiter e o conecta à admissão HTTP/WebSocket. A conclusão correta não é “não existe” nem “está perfeito”; é que a documentação ficou atrás da implementação e precisa ser alinhada antes de servir como contrato de segurança.

Buzz Mesh e agentes remotos

O projeto vai além da colaboração. O Buzz Mesh usa identidade de comunidade para compartilhar compute entre membros, com transporte QUIC/Iroh e um endpoint compatível com modelos locais. A tese é: pessoas que já confiam umas nas outras podem compartilhar GPUs sem entregar prompts a um provedor externo. O custo honesto também está documentado: o prompt deixa a máquina e vai para alguém da comunidade.

A visão de agentes remotos segue o mesmo princípio. O desktop faz o handoff inicial para um provider, mas depois não mantém um canal secreto de controle sobre o substrato. O agente conversa, recebe comandos e encerra pelo relay; a máquina onde ele roda é substituível. Isso reduz uma superfície de gerenciamento, embora também elimine um kill switch garantido quando o agente ou a infraestrutura está travado.

Comparação com OpenBot e 9Router

Depois das duas pesquisas anteriores, a divisão aparece assim:

Buzz     → onde humanos, agentes, código e memória se encontram
OpenBot  → como um agente executa browser, arquivos e MCP com política
9Router  → por qual modelo, conta e provedor a inferência passa

Buzz não substitui o OpenBot: pode ser o espaço de coordenação onde a tarefa, a aprovação e o resultado são registrados, enquanto OpenBot executa a ação governada. Buzz também não substitui o 9Router: um agente ACP poderia, em tese, usar um endpoint compatível fornecido pelo Router, mas não encontrei integração nativa entre os dois no snapshot.

Meu veredito para o Rabelus Lab

Buzz é o projeto mais próximo, entre os três, da ideia de um Quantum Bus visível e operacional. Ele transforma identidade, memória, colaboração e execução em eventos assinados; o nosso bus hoje faz isso por arquivos, Git e convenções. A semelhança conceitual é grande, mas a topologia é diferente: Buzz exige Postgres, Redis, MinIO/S3 e um relay Rust; não é uma ferramenta leve para simplesmente copiar para uma pasta.

Eu o avaliaria como plano de colaboração e coordenação agentiva, em laboratório isolado. Não o adotaria ainda como substituto direto do Quantum Bus nem como infraestrutura de produção sem validar backups, recuperação de chaves, TLS, fronteiras multi-community, workflows de aprovação e políticas de membership.

O aprendizado que vale absorver mesmo sem instalar é poderoso: agentes precisam de identidade própria; ações importantes devem virar eventos; conversas, patches e decisões devem compartilhar um log; e a memória útil precisa ser pesquisável no mesmo lugar em que o trabalho acontece.

O OpenBot governa a mão. O 9Router governa a estrada do pensamento. O Buzz tenta construir a sala onde humanos e agentes lembram, discutem, trabalham e deixam prova do que fizeram.