Block agrega una forja Git experimental autoalojada a Buzz
La versión beta vincula repositorios, revisiones y conversaciones del proyecto con identidades portátiles de Nostr para personas y agentes de IA en el relay propio del equipo.
By Ryan Merket · Published
Primary source: X
Why it matters
Buzz Projects moves AI agents from integrations to identifiable contributors with their own signed histories and permissions. If Block completes the forge layer, teams could keep code, agent work and the decisions behind both on infrastructure they control.

Jack Dorsey (@jack) presentó Buzz Projects como una "alternativa autosoberana a GitHub" el martes, señalando una nueva publicación de Block Engineering que detalla cómo Buzz puede alojar repositorios Git, revisiones de código y las conversaciones en torno a ellos en un relay controlado por el usuario.
La función extiende a Buzz, el espacio de trabajo de código abierto de Block para humanos y agentes de IA, hacia el territorio ocupado por GitHub y GitLab. Repositorios, issues, pull requests, actividad de agentes y discusiones de equipo están bajo un mismo proyecto en lugar de estar divididos entre una forja de código, un servicio de chat y una interfaz de agentes.
El relay se convierte en la forja de software
Thomas Petersen, un diseñador principal y constructor en Block, escribió que el equipo diseñó Projects para preservar la cadena que conecta una idea, su discusión, el código producido a partir de ella y la eventual revisión y liberación. Ese historial se convierte en contexto utilizable para agentes que trabajan dentro de la misma comunidad de Buzz.
Un Buzz Project puede agrupar múltiples repositorios con canales y actividad relacionadas. Block afirma que los usuarios pueden alojar repositorios Git estándar en su propio relay y hacer fetch, clone, pull o push sobre Smart HTTP sin instalar un wrapper propietario ni conectar una cuenta de GitHub.
La identidad proviene de las claves Nostr. La misma clave que firma los mensajes de una persona puede autenticar un push de código, mientras que un agente recibe su propia clave e historial de contribuciones. Buzz registra pushes, revisiones, aprobaciones y merges como eventos firmados, dando a los operadores una forma de distinguir el trabajo producido por un agente de la autorización humana que lo respalda.
Esa distinción se está volviendo importante a medida que los agentes de codificación van más allá del autocompletado y empiezan a abrir pull requests, revisar parches y ejecutar flujos de trabajo de lanzamiento. Las plataformas de desarrollo existentes generalmente tratan a un agente como una integración que actúa a través de una cuenta de servicio o las credenciales de un usuario. Buzz le da al agente una identidad separada dentro del espacio de trabajo, con la pertenencia a canales controlando a qué puede acceder.
Los usuarios pueden explorar archivos y commits, inspeccionar diffs, dejar comentarios en línea y mergear cambios desde la interfaz de Buzz, según la publicación de Block. Un proyecto también puede vincular repositorios a los canales donde se discutió el trabajo. Un agente asignado a un issue puede abrir un pull request que enlace de vuelta a la conversación originaria, y luego notificar a un humano cuando se requiera una revisión o decisión.
Git funciona hoy; gran parte de la forja aún se está armando
Block está etiquetando a Projects como un experimento, y la distinción importa. El repositorio público de Buzz lista el relay, la aplicación de escritorio, el soporte de eventos Git y el backend de alojamiento Git como funcionales. Los clientes móviles y las puertas de aprobación de flujos de trabajo permanecen en construcción.
El documento de diseño de Projects más detallado de Buzz traza una línea aún más clara. El alojamiento de Git sobre Smart HTTP y la especificación NIP-34 de Nostr están disponibles hoy, mientras que el enlace de proyectos multi-repositorio, el coordinador de merges, los issues de NIP-34 y un sistema de reputación portátil están listados como trabajo diseñado en lugar de capacidades terminadas.
El resultado es una forja temprana en lugar de un reemplazo de GitHub función por función. Block tiene el transporte de repositorios, el modelo de eventos firmados y el espacio de trabajo para agentes en su lugar. La capa más difícil —gestión madura de issues, automatización de merges, controles de acceso y la fiabilidad operativa esperada de un sistema que alberga código fuente de producción— sigue siendo el trabajo por delante.
Buzz también presenta las aristas normales de un producto joven para desarrolladores autohospedado. La página de GitHub dice que la versión de escritorio para Windows no está firmada, mientras que ejecutar un relay desde el código fuente requiere Docker y una cadena de herramientas de desarrollo fijada. La última versión de escritorio empaquetada, versión 0.5.14, se publicó el 15 de agosto.
Block quiere el historial del proyecto, no solo el repositorio
La apuesta competitiva de Buzz descansa en el contexto. GitHub ya almacena código, revisiones e issues, mientras que las conversaciones de trabajo e instrucciones a agentes a menudo permanecen en sistemas separados. Buzz pone esos registros en un único registro de eventos firmados y un único índice de búsqueda, permitiendo a un agente recuperar la discusión que produjo un parche en lugar de inferir la intención solo a partir del código y del ticket.
El autohospedaje también cambia el punto de control. Un equipo puede operar el relay bajo su propio dominio, retener los eventos subyacentes y mover identidades Nostr compatibles o metadatos de repositorios a otros clientes. El documento de diseño de Block dice que clientes NIP-34 estándar aún pueden leer los repositorios individuales incluso cuando ignoren las agrupaciones de proyectos específicas de Buzz.
La afirmación de portabilidad dependerá de la adopción fuera del propio cliente e implementación de relay de Block. Por ahora, Buzz Projects le da a Dorsey y a Petersen una demostración funcional de la tesis: código, discusión en el lugar de trabajo y agentes autónomos pueden compartir un sistema de identidad sin enrutar todo el historial de desarrollo a través de GitHub. El experimento todavía tiene que demostrar que los equipos aceptarán la carga operativa y las herramientas incompletas que vienen con poseer la alternativa.