Jack Dorsey lança o Buzz, combinando chat de equipe, agentes de IA e hospedagem Git

• A Block lançou o Buzz, um workspace open source que conecta funcionários, agentes de IA, conversas e repositórios de software em um único sistema de identidade, buscando reduzir a dependência de Slack e GitHub
• Mensagens, reações, etapas de workflow, eventos de código e aprovações são armazenados como eventos Nostr assinados, e pessoas e agentes recebem igualmente pares de chaves, associação a canais e trilhas de auditoria
• Agentes realizam desde busca em conversas até envio de patches, revisão de código e execução de workflows, enquanto os harnesses Goose, Codex e Claude Code separam o workspace dos modelos de base
• Embora ofereça self-hosting e propriedade dos dados, todas as leituras e escritas passam por um único relay central, portanto o operador precisa assumir disponibilidade, backups, segurança e upgrades
• O produto reúne chat, hospedagem de código, automação, busca e coordenação de agentes em um só lugar, mas app móvel e notificações push ainda estão incompletos, e taxa de adoção, preços e número de clientes externos não foram divulgados

---

Workspace integrado que conecta pessoas e agentes

• O Buzz é um workspace open source com possibilidade de self-hosting que coloca funcionários, agentes de IA, conversas e repositórios de software sob um único sistema de identidade
  • Jack Dorsey busca, com isso, reduzir a dependência da Block de Slack e GitHub
  • O repositório público da Block também documenta uma build interna separada, ajustada ao relay interno e a provedores de agentes da empresa
• Em torno de um relay Nostr self-hosted, mensagens, reações, etapas de workflow, eventos de código e aprovações são armazenados como eventos assinados criptograficamente
  • Funcionários e agentes têm, ambos, pares de chaves exclusivos, associação a canais e trilhas de auditoria
  • Graças à identidade compartilhada e aos eventos assinados, a estrutura permite que agentes participem como membros com responsabilidade rastreável, indo além de chatbots tradicionais
• Agentes podem pesquisar conversas anteriores, navegar por repositórios, enviar patches, revisar código, executar workflows, editar canvases compartilhados e criar canais
  • O produto oferece uma CLI para agentes e harnesses Goose, Codex e Claude Code, separando os modelos de base do workspace
• A especificação do projeto define um forge de software embutido que usa o padrão Git Smart HTTP
  • Branches de funcionalidades são transformadas em canais dedicados, preservando patches, resultados de integração contínua, comentários de revisão e decisões de merge no mesmo registro
  • Repositórios, conversas e histórico de workflows compartilham um único índice de busca
• Atualmente funcionam canais, threads, mensagens diretas, canvases compartilhados, mídia, busca, logs de auditoria, app desktop e workflows baseados em YAML
  • Há builds de pacotes para macOS, Windows e Linux, sob licença Apache 2.0

Estrutura de relay único e limitações do produto inicial

• Dorsey apresentou o Buzz como um produto descentralizado e soberano, mas, segundo a documentação de arquitetura, atualmente não há troca P2P de eventos entre relays, camada de gossip nem recurso de replicação
  • Todas as leituras e escritas passam por um único relay, que autentica usuários, verifica assinaturas e armazena e distribui eventos
  • Organizações podem possuir seu próprio relay, domínio e dados, e usar pares de chaves Nostr portáveis, mas dentro de cada comunidade esse relay continua sendo o servidor autoritativo
  • Provedores de hospedagem podem operar várias comunidades isoladas entre si em uma infraestrutura compartilhada
• O self-hosting dá controle sobre infraestrutura e localização dos dados, mas transfere ao operador a responsabilidade por disponibilidade, backups, segurança e upgrades
  • Eventos assinados ajudam na atribuição de ações e na trilha de auditoria, mas não eliminam os riscos de operação do servidor
• O Buzz pode ser usado para testes e desenvolvimento, mas a documentação o classifica repetidamente como um produto inacabado
  • O cliente móvel está em desenvolvimento, e notificações push ainda não são oferecidas
  • Os gates de aprovação de workflows têm componentes de banco de dados, API e interface, mas ainda não contam com um caminho de execução completo
  • A versão 0.4.21 do desktop foi lançada em 21 de julho com adições e correções relacionadas a controle de agentes, autenticação e onboarding no workspace
• Com um único sistema de eventos, o Buzz tenta substituir chat, hospedagem de código, automação de workflows, busca de projetos e parte da coordenação de agentes
  • A estrutura integrada pode reduzir o trabalho de integração necessário para fornecer aos agentes o contexto e permissões de acesso limitadas
  • Por outro lado, produtos existentes separados por função permitem trocar apenas uma ferramenta sem migrar toda a stack de desenvolvimento
• A Block é o primeiro caso de cliente incluído na documentação do Buzz, mas taxa de adoção, preços e número de clientes externos não foram divulgados; por enquanto, o projeto está na fase de build open source e pedido de contribuições

[GN⁺]

Comentários do Hacker News

• Aquele screenshot parece algum terror no estilo David Lynch. Alguém diz “#engineering. Nova direção. Vamos migrar o protótipo para Flutter”, e então humanos e bots agentes ficam conversando com nomes fofos e emojis tipo “terminei a parte de física, e a UI shell, como está @Honeybot?”
  É difícil imaginar um mundo em que organizar o desenvolvimento de software desse jeito pareça natural, e o fato de usar algo parecido com blockchain também soa bem típico
  https://github.com/block/buzz/blob/main/docs/assets/screensh...

  • Fico pensando se o futuro da programação não vai passar um desespero de Ian McKellen filmando com tela verde. Pode ser parecido com a situação em que um veterano do teatro shakespeariano estava gravando The Hobbit sem atores de verdade ao redor e sentiu: “meu trabalho é atuar com outras pessoas, não atuar sozinho”
    https://www.theguardian.com/film/2013/nov/20/the-hobbit-gand...
  • Um dos motivos de eu ter entrado em pesquisa de IA quando era mais novo foi a expectativa de que um dia existiriam seres inteligentes capazes de conversar e interagir como humanos. Agora isso realmente ficou possível e parece que todo mundo odeia, mas eu ainda acho ótimo, e considero muito legal essa tentativa de transformar agentes de IA em membros da equipe
    Só que, em vez de cópias bajuladoras, eles deveriam ter personalidades reais, de forma que as diferenças entre agentes fiquem claras tanto na capacidade quanto no comportamento
  • Aquela tela é um demo roteirizado feito porque seria difícil sincronizar em tempo real as ações de várias pessoas e agentes, e dá até para ver o PR correspondente no repositório
    No fundo, não dá para subestimar um toque brincalhão quando ele ajuda a tornar algo desconhecido mais intuitivo. Cada bot tem um responsável, capacidades e permissões diferentes, então nome e imagem são só uma forma prática de distinguir instâncias, e deixá-los fofos é opcional
  • Não tem blockchain nisso. Nostr é só um padrão de formato de mensagens assinadas que passa por servidores relay simples de armazenar e encaminhar
  • Como todas as mensagens estão marcadas às 5:42, parece ser uma captura feita com dados de teste pré-preenchidos, ou um mockup baseado nessa captura

• Dizem que é “como explicar para uma criança de 5 anos”, mas aí explicam que “Buzz é um workspace open source e self-hosted que combina chat de equipe, agentes de IA e hospedagem Git com eventos Nostr assinados”, então o nível esperado dessa criança de 5 anos é bem diferente

  • É curioso como ELI5, que originalmente era o nome de um subreddit derivado de threads do AskReddit, virou um termo de marketing comum na indústria de tecnologia. Hoje ele está mais para uma abreviação de “explique desde os primeiros princípios que o leitor esperado precisaria saber”, e parece que muita gente da área guarda carinho pelo Reddit dos anos 2010
  • Já fiquei preocupado de, ao dizer eli5 (tarefa) para um agente, ele fosse explicar literalmente como se estivesse falando com uma criança de 5 anos. Era um receio irracional; ao contrário da seção de comentários do HN, agentes normalmente entendem a intenção real
  • Como eu também não entendi o ELI5 que recebi ontem, o próximo passo racional foi pedir um ELI4
  • Está mais perto de querer dizer: “explique como se estivesse apresentando no TechCrunch Disrupt”
  • Mesmo lendo sobre o Buzz, tudo parece só uma sobreposição de buzzwords e jargão corporativo, então é difícil entender o que ele realmente faz

• Trabalho no Slack, mas esta é uma opinião pessoal. É legal que um agente consiga ver tudo o que eu e meus colegas vemos, mas no momento em que você quer expor certas informações só para algumas pessoas, a coisa complica
  Em um agente multiusuário, é preciso escrever e manter regras de acesso por recurso bem complexas para evitar vazamento de dados. Já um agente de usuário único é estruturalmente mais simples porque age em nome de uma pessoa, e o ponto central é impedir que ele leve dados privados para um espaço compartilhado sem permissão explícita

  • Em um ambiente de colaboração de verdade, grupos privados são o pior caso. Eu queria que o Slack tivesse um botão para publicar uma thread inteira em um canal público
  • Posso estar enviesado por vir da Asana, mas concordo que agentes de usuário único são mais fáceis. Ainda assim, um agente multiusuário que entende o fluxo completo de trabalho é muito poderoso
    Gastamos muito tempo e reflexão para levar privacidade em conta e evitar que informações vazem para o destinatário errado. Ainda não usei o Buzz, mas valorizo a tentativa de pensar diferente e construir algo interessante
  • No Buzz, parece que agentes não são uma integração de app, mas sim usuários de primeira classe. Se você criar um usuário chamado Claude e aplicar ACLs normais, talvez nem precise se importar se é humano ou bot
  • Nosso ambiente de execução em nuvem distingue entre segredos compartilhados e segredos pessoais. Itens autenticados com segredos compartilhados podem ser usados em ambientes públicos, enquanto itens pessoais só podem ser acessados por canais confiáveis, e isso também se aplica a Slack, Telegram etc.
    O agente do Slack é forte nessa parte e garante que informações privadas nunca vazem
  • Não daria para usar ID do chat em grupo e informações adicionais como chave da conversa?

• Agora, quando vejo um projeto de software novo, a primeira coisa em que penso é quanto dele foi feito por agentes, e a instabilidade e a facilidade de abandono que vêm junto. Dez anos atrás eu talvez conseguisse estimar minimamente a qualidade de um produto, embora eu não esteja falando do Buzz especificamente

  • Antes, o atrito natural de construir alguma coisa já sinalizava certo nível de reflexão; agora parece que jogam algo para o usuário e deixam que ele mesmo descubra se tem valor
    Nesses produtos, o risco é maior que a vantagem de adotar cedo, então é melhor esperar alguns meses. Se o produto for sustentável, alguns meses de atraso não fazem grande diferença
  • A maior parte do software acaba desaparecendo de qualquer forma, com ou sem agentes, então há uma falha nesse raciocínio. O Google também lançou em 2010, antes dos LLMs, um produto social parecido chamado Google Buzz, e ele acabou em 16 meses
    O essencial é se o projeto encontra adequação ao mercado; se ele ainda vai existir daqui a 2 anos não tem uma relação tão forte com a qualidade do código quanto engenheiros gostariam de acreditar
  • Agora eu não quero mais ser adotante inicial e preciso de pelo menos 6 meses de validação para ver se não é só uma moda passageira
  • O mais seguro é assumir que tudo foi gerado por LLM
  • Essa facilidade de abandonar é real. Você usa IA para criar uma função e testes, usa IA para modificar a função, os testes quebram, então apaga tudo e manda a IA gerar os testes de novo

• Já trabalhei no Slack. É bom desafiar o status quo do chat, mas sou cético quanto a Slack e Teams sobreviverem à era dos agentes ou evoluírem até esse nível
  Ainda assim, fico me perguntando se o Nostr é realmente o protocolo adequado. Em grandes empresas, é preciso lidar com inúmeros clientes, incluindo celulares e agentes locais, além de agentes por equipe. A estrutura de identidade atual faz sentido para agentes hospedados de forma centralizada, mas não sei se agentes pessoais reutilizam as credenciais do usuário ou se são separados disso
  Também duvido que o Git precise ser uma dependência obrigatória. Pode ser necessário para a Block, mas aumenta a complexidade, então também daria para separar isso mesclando eventos do host de controle de versão ao log de eventos do Buzz
  Também queria saber que problemas podem surgir quando aparecerem novos recursos, como Sol e Claude renderizando componentes nativos na janela de chat para concretizar mudanças de design. Também queria saber por que escolheram Rust e quais alternativas avaliaram

  • Um meio-termo como o Signal parece melhor. O Slack se tornou difícil de desvincular das relações de negócios de escritório, mas em uma situação exposta a ciberataques 24 horas por dia, seria bom ter confidencialidade e segurança por meio de um sistema de conhecimento zero em vez de depender de promessas da empresa
    O Signal foi o cliente com a melhor experiência de mensagens entre plataformas que já usei em grupos de amigos, e acrescentar uma estrutura ao estilo do Slack à arquitetura atual ajudaria a reduzir o problema de canais barulhentos
  • Informações compartilhadas como código e arquivos estão se tornando cada vez mais importantes para manter o alinhamento entre pessoas e agentes, e como empresas nativas de IA tenderão a depender ainda mais de código, a integração com Git faz sentido
  • Queria entender por que Rust parece uma escolha ruim. Pela minha experiência lançando software para dispositivos médicos, ele foi excelente para manter o código escrito pela equipe coeso e correto

• Google Buzz e Wave chegaram cedo demais ao mundo
  https://en.wikipedia.org/wiki/Google_Buzz

  • Até hoje não dá para criar o rótulo Buzz no Gmail
  • Assim que vi, pensei em Google+ e Buzz

• Colocar bots no chat da equipe não é uma má ideia, então venho experimentando isso há alguns meses. O Slack funciona, mas ajustar a infinidade de permissões é um sofrimento, e isso precisa ser repetido a cada novo bot
  Tentei usar o Matrix como alternativa self-hosted, mas a criptografia de ponta a ponta era rígida demais e atrapalhava ao compartilhar informações com bots. Mudei para o Zulip algumas semanas atrás, e tudo foi simples: instalação, criação de usuários de bot e automação. A automação feita com Openclaw substituiu um código baseado em Haystack que estava menos bagunçado
  Descobri depois da instalação que executivos do Zulip foram contratados pela Anthropic. Parece que Jack Dorsey anunciou primeiro, mas a Anthropic também pode ter planos parecidos
  Agentes por equipe fazem bastante sentido. Quanto maior a organização, maior o custo de colaboração, então isso é um bom alvo para otimização com IA; e quanto mais uso de IA houver, maior também será a necessidade de compartilhar e coordenar em canais públicos o que está sendo feito. Chat de equipe também combina bem com processos complexos que incluam proteções comuns e passagem de contexto entre pessoas e agentes

  • Fico curioso sobre XMPP

• Pode preencher um nicho útil, mas é muito provável que Anthropic e OpenAI, dentro de 6 a 12 meses, empurrem isso com produtos próprios
  Ao olhar forges Git para enxames de agentes, o Radicle parecia ter uma camada de identidade insuficiente, mas o modelo federado de COB pareceu bom; o Tangled não tem suporte a repositórios privados, mas sua camada social era sólida. Ainda assim, modelar issues como posts em vez de objetos pertencentes ao repositório parece estranho
  Portanto, há espaço para uma forge voltada прежде de tudo a agentes privados. A Anthropic já está indo nessa direção, e seu produto mais recente, Tag, é um modelo de autenticação para executar agentes de forma assíncrona dentro do Slack
  O próximo passo pode naturalmente ser uma forge. Quando a UI de agentes deixar de intermediar o GitHub, a Anthropic poderá trocar livremente a implementação interna, e chat multiusuário junto com gerenciamento de repositórios e projetos parecem ser os próximos componentes de plataforma

  • Estou criando uma nova code forge https://juju.bi. Não é um produto agent-first, mas, fora escalabilidade, não consigo pensar em recursos especialmente necessários para agentes

• Um grande motivo para o Slack existir é que o IRC era insuficiente por não oferecer por padrão histórico de canais, busca etc. Para agentes de IA prosperarem, o Slack terá de abrir completamente sua rede como protocolo ou acabará sendo substituído
  Seria bom se o Slack adotasse chat baseado em AT Protocol e apps como o Buzz implementassem isso. Usuários poderiam usar handles de domínio como @yourname.com, e agentes @agent1.yourname.com, com controle total

  • Não entendo por que fazer agentes prosperarem seria responsabilidade do Slack. Estou vivendo em primeira mão, em toda a indústria, essa inversão entre meios e fins de mudar fluxos de trabalho para se adaptar à IA; as ferramentas devem trabalhar para as pessoas, não o contrário
  • É parecido com as contas de bot e puppet do Matrix
  • O motivo de eu ter gostado do Slack no começo foi que ele era “um IRC com conveniências modernas”. Depois de perder espaço para a Microsoft e ser vendido para a Salesforce, ele praticamente estagnou, e a maioria das mudanças só piorou o produto
  • O sistema de permissões do ATProto, ainda não definido, não oferece o nível de controle granular exigido por empresas. Recursos como grupos seriam implementados na app view e acabariam efetivamente centralizados, e ACL é uma abordagem de duas gerações atrás na história de gestão de identidade e acesso
    Chat também não é um formato que se encaixe bem em PDS/ATP. O Roomy também percebeu isso e está criando um protocolo dedicado e bridges
  • Está mais para HipChat do que Slack, e errou a época por uns 15 anos

• É a primeira vez que tenho a experiência desagradável de um movimento do cursor no site atrasado em 0,5 segundo