# petersen-block-buzz-projects-forge-souveraine-2026-08-18

## Veille

Publicación de anuncio de producto de **Block Engineering** firmada por **Thomas Petersen** (*Principal Designer & Builder*), publicada el **18 de agosto de 2026**, ~1.800 palabras en trece secciones breves, que presenta **Buzz Projects** — una **forja de software alojada en su propio relay**: repositorios Git, ramas, pull requests, issues, revisión y merge, proyectos multi-repositorio, un feed de actividad, todo vinculado a canales de conversación. El planteamiento y la tesis de la publicación: *« Coding agents are the terminal for your computer. Buzz is the terminal for your network. »* Tres aportaciones. **(A) Una doctrina de confianza fundada en la prueba *a posteriori* más que en la autorización *a priori***: por un lado *« No forced guardrails, no limitations on what your agents are allowed to help you with »*, por otro *« Every push, review, approval, and merge is a signed Nostr event. If an agent authors a patch, you can see which agent produced it and which human authorized that agent to act »*; la sección se cierra con una dirección enunciada — *« we are already exploring ideas around agent trust protocols informed by past behavior »*. **(B) Interoperabilidad Git sin herramientas propietarias**: *« These are standard git repositories… You can fetch, clone, pull, and push over plain Smart HTTP, with no custom tooling or wrapper CLI required »*, con la clé Nostr sirviendo como identidad única — *« The same npub that signs your messages signs your pushes. »* **(C) Una distinción entre superficie de ejecución y presencia en la red**: *« A terminal gives an agent somewhere to execute commands and change files, but it does not give it a persistent place in the network. Buzz does. »* La publicación no aporta ninguna cifra y no contiene enlaces salientes; se califica a sí misma de preliminar seis veces (*« still very basic »*, *« fairly elementary »*, *« still under experiments »*), y Projects se encuentra bajo la pestaña **Experiments** de Buzz Desktop.

## Titre Article

Projects in Buzz

## Date

2026-08-18

## URL

https://engineering.block.xyz/blog/projects-in-buzz

## Keywords

Buzz, Buzz Projects, Block, Block Engineering, Thomas Petersen, forja de software, forja de software, relay, relay, Nostr, npub, identidad portátil, evento firmado, evento Nostr firmado, hosted git, hosted git, Smart HTTP, fetch clone pull push, sin herramientas propietarias, proyecto multi-repositorio, pull request, issue, revisión de código, diff, merge, CI, notas de versión, feed de actividad, pestaña Experiments, Buzz Desktop, vinculación proyecto-canal, contexto compartido, el contexto es todo lo que se necesita, historial de contribuciones, historial verificable, reputación de agentes, protocolos de confianza de agentes, comportamiento pasado, autorización a priori, prueba a posteriori, sin guardrails forzados, soberanía, protocolo abierto, terminal para tu red, presencia persistente en red, fragmentación de herramientas, beta, experimental, AIArchitecture

## Authors

**Thomas Petersen** — *« Principal Designer & Builder »* chez **Block**, auteur unique et signataire du billet ; première apparition dans le corpus. Publié le **18 août 2026** sur le blog **Block Engineering**. Troisième signature Block sur Buzz en un mois, après Tyler Longwell (21 juillet) et Atish Patel (6 août), et la première non-ingénieur.

## Ton

**Perfil**: un manifiesto de producto en forma de recorrido guiado — ~1.800 palabras, trece secciones breves con títulos-eslogan, una captura de pantalla por funcionalidad. Audiencia: usuarios existentes de Buzz Desktop (*« If you've used Buzz Desktop recently and happened to click on the Experiments tab… »*) y, de manera implícita, cualquiera que esté evaluando una alternativa a GitHub. Una demo narrada acompañada de una posición, ni un informe de diseño ni un benchmark.

**Estilo**: la página está enmarcada por prompts de shell simulados — `$ cd ~`, `$ find .`, `$ git blame`, `$ cat content.md`, `$ echo "Copyright 2026 Block, Inc."` — el planteamiento anuncia *« Buzz is the terminal for your network »* y la maquetación lo escenifica. Los títulos de sección son tesis más que descripciones (*« Context is (almost) all you need »*, *« All conversations lead to projects and back »*, *« Your project, your relay »*, *« Autonomy, sovereignty and the big picture »*); el *« (almost) »* del primero es la única matización del texto y nunca se desarrolla. La autolimitación es sistemática: seis advertencias explícitas, incluido un *Disclaimer* nombrado como tal en la última línea — *« Buzz is still in beta and Buzz Projects is still under experiments, so treat it accordingly. »* La prosa está escrita deprisa, con dos frases rotas en el original: una sin sujeto gramatical (*« Whether we are talking repos, branches, pull requests, issues, CI, or all the related conversations gives you and your agents unique identities that you control »*), la otra con un verbo truncado (*« new scenarios we have solve »*). El "nosotros" del producto reemplaza al "yo" del ingeniero: *« We believe those things belong together »*, *« we think this distinction will become increasingly important »*.

**Frases distintivas**:
- ***« Coding agents are the terminal for your computer. Buzz is the terminal for your network. »***
- ***« Software development tools are fragmented in ways the work itself is not. »***
- ***« The history becomes part of the project itself. »***
- ***« No forced guardrails, no limitations on what your agents are allowed to help you with. »***
- ***« a software forge that lives on your relay, letting you own all the relationships »***
- ***« The same npub that signs your messages signs your pushes. »***
- ***« no two agents in Buzz work the same way because they have different context. They have different context because they have a different history. »***
- ***« Every push, review, approval, and merge is a signed Nostr event. »***
- ***« more than a set of colored squares on a profile »***
- ***« agent trust protocols informed by past behavior »***
- ***« A terminal gives an agent somewhere to execute commands and change files, but it does not give it a persistent place in the network. Buzz does. »***
- ***« either way the protocol is open and the events are yours »***

**Estatus epistémico**: una doctrina de diseño ilustrada con capturas de pantalla, sin ningún dato — ni un usuario, ni un repositorio, ni una duración, ni un coste, ni un benchmark — y sin ningún enlace saliente en toda la página. Citable como posición arquitectónica de Block sobre lo que debería ser una forja en la era de los agentes; no como prueba de funcionamiento, ni como indicio de adopción.

## Pense-betes

- **Fecha / fuente**: **18 de agosto de 2026**, blog de **Block Engineering**, ~1.800 palabras, firmado por **Thomas Petersen** (*Principal Designer & Builder*). Sin enlaces salientes, sin cifras.
- **Planteamiento clave**: Buzz Projects es una forja en la que **la conversación es un artefacto de primer orden** — los proyectos se vinculan a canales, y *« Instead of reconstructing why something happened after the fact, the history is already there. »* ### El modelo de confianza: dos párrafos que deben leerse juntos | Sección de la publicación | Cita textual | Qué establece | |---|---|---| | *First Class Citizens* | *« No forced guardrails, no limitations on what your agents are allowed to help you with. No limits to how much you can delegate to your agents in the network. »* | supresión de la restricción previa | | *Weaving it all together* | *« Every push, review, approval, and merge is a signed Nostr event. If an agent authors a patch, you can see which agent produced it and which human authorized that agent to act. »* | registro firmado del acto | | mismo párrafo, cierre | *« we are already exploring ideas around agent trust protocols informed by past behavior »* | derivar la confianza a partir del historial | La posición es arquitectónica: en una red donde la delegación es ilimitada, la autorización *a priori* escala mal, la firma no. Es la versión "de red" de lo que [[longwell-block-buzz-workspace-agents-nostr-2026-07-21]] expuso en julio a nivel de identidad (*« authorization does not erase authorship »*). Dos limitaciones que la publicación no aborda: un registro *a posteriori* no impide la primera instancia de daño, y un historial firmado prueba lo que se hizo, no la completitud de lo que se muestra — sería necesario un registro negativo (PR rechazados, regresiones, incidentes) para una reputación, y no se menciona. ### Qué garantiza la firma, y qué no | Garantizado | No garantizado | |---|---| | el evento fue efectivamente producido por esa clave | que la clave produjo **todo** lo que se muestra de ella | | la integridad de cada evento aislado | la **completitud** del conjunto presentado | | el vínculo agente autorizante → humano | la **detectabilidad** de eventos fuera de su relay de origen | Punto arquitectónico que no debe atribuirse a esta publicación: el relay es la única fuente de verdad, sin replicación ni intercambio entre pares. Esto proviene del `ARCHITECTURE.md` de Block tal como se consolida en [[buzz-block-panorama-deep-research-2026-08-12]], no de este texto, que no dice nada al respecto. Consecuencia: la soberanía ofrecida es un **derecho de salida**, no una garantía de disponibilidad. ### Interoperabilidad Git: la afirmación más verificable Cita textual: *« These are standard git repositories, like you already know them… You can fetch, clone, pull, and push over plain Smart HTTP, with no custom tooling or wrapper CLI required. Your Nostr key is your identity throughout the process… You do not need another account, another identity, a separate token, or a GitHub account connected in the background. »* Consecuencias: el coste de salida es bajo por construcción (un `git clone` recupera el código), y la identidad única elimina la gestión de tokens. Matiz a retener: **solo el código es estándar** — la conversación, la revisión, el vínculo PR↔canal y el historial de contribuciones residen en *event kinds* de Nostr específicos de Buzz. Una prueba realizable en diez minutos: `clone` y luego `push` desde un cliente Git puro contra un relay Buzz, sin la CLI `buzz`. ### Inventario anunciado vs. inventario entregado El párrafo de apertura enumera seis fragmentos por reunir; la sección *« What's next? »* enumera lo que existe. | Fragmento nombrado en la apertura | Presente en el inventario del 18 de agosto | |---|---| | *« A bug report lands in one tool »* | sí — issues | | *« The discussion happens in another »* | sí — canales vinculados al proyecto | | *« The fix lives on a branch somewhere else »* | sí — *hosted git*, multi-repositorio | | *« Review happens in a comment thread attached to a diff »* | sí — PR, revisiones, comentarios en línea | | *« CI runs in another system »* | **no** — citado entre las promesas, ausente del inventario | | *« Release notes get written later »* | **no** | Seis fragmentos anunciados, cuatro entregados. No reutilizar la lista "repos, branches, pull requests, issues, CI, or all the related conversations" como inventario de funcionalidades ya lanzadas. ### Distinción que merece reutilizarse: ejecutar no es lo mismo que estar presente | Lo que un terminal da a un agente | Lo que añade la presencia en red | |---|---| | ejecutar, escribir archivos | una **identidad estable** que otros pueden dirigirse a ella | | estado local, desechable | un **historial adjunto** que sobrevive a la sesión | | actuar | **rendir cuentas** de lo hecho | Un marco útil para sopesar un agente-herramienta (invocado) frente a un agente-miembro (interpelado). Corolario que la publicación no aborda: una presencia persistente es también una superficie de ataque persistente — ver [[valente-zalewski-beyond-zero-enterprise-security-ai-era-2026-07-20]]. ### "El contexto es (casi) todo lo que se necesita" Cita textual: *« The more context we can make available, the better equipped the agents are, the more intelligent the whole network becomes. »* La monotonicidad se afirma sin argumento: no se discute ni el coste del contexto, ni su degradación, ni su selección, y el *« (almost) »* nunca se desarrolla. Merece compararse con el presupuesto de tokens cuantificado en el propio Block por [[patel-block-buzz-teams-tokens-benchmarks-2026-08-06]]. ### El único efecto reivindicado por la publicación *« We've already seen a number of examples where agents understood context humans didn't and helped course correct otherwise unproductive directions. »* Sin ejemplo, sin cifra, sin criterio de éxito. Formulación correcta para reutilizar: *« Block reports, without documenting them, cases where agents redirected unproductive directions using channel context. »* Ficha por reabrir si Block publica estos casos. ### Higiene de citación 1. Citable como **intención arquitectónica** de Block; no como prueba de funcionamiento ni de adopción. 2. Llevar siempre la madurez declarada: pestaña **Experiments**, *« fairly elementary »*, Buzz *« still in beta »*. 3. Distinguir las funcionalidades mostradas en capturas de pantalla, las inventariadas bajo *« What's next? »*, y las solo nombradas en frases de promesa (CI, notas de versión). 4. Los *« agent trust protocols »* son una dirección declarada, sin esquema, sin criterio, sin calendario.

## RésuméDe400mots

Publicación de anuncio de **Block Engineering** firmada por **Thomas Petersen** (*Principal Designer & Builder*), publicada el **18 de agosto de 2026**, que presenta **Buzz Projects** — el componente de forja de **Buzz**, el espacio de trabajo humanos+agentes de Block construido sobre **Nostr**.

**El problema planteado.** *« Software development tools are fragmented in ways the work itself is not. »* El reporte de bug está en una herramienta, la discusión en otra, la corrección en una rama, la CI en otro sitio, la revisión en un hilo de comentarios, las notas de versión reconstruidas después. **La tesis: todo esto es una sola conversación, y el historial debe formar parte del proyecto.**

**Lo que aporta Projects.** Una **forja alojada en el propio relay**: repositorios Git estándar accesibles mediante `fetch/clone/pull/push` sobre **Smart HTTP**, *« with no custom tooling or wrapper CLI required »*; **la clé Nostr como identidad única** — *« the same npub that signs your messages signs your pushes »*, sin token separado ni cuenta de GitHub; **proyectos multi-repositorio** que pueden incluir repositorios que uno no posee (*« you just won't have authority over it »*); issues, pull requests, diffs, comentarios en línea, revisión y merge; un **feed de actividad** a nivel de servidor; y la **vinculación de cualquier proyecto con cualquier número de canales**, de modo que *« el contexto en torno a un cambio no desaparece en cuanto los agentes empiezan a escribir código »*. Desde un canal, un issue puede encomendarse a un agente o puede pedírsele al agente que abra un PR, que se vincula de vuelta a la conversación que lo produjo; el agente se dirige al humano a través del **Inbox**.

**La doctrina, en dos partes que la publicación nunca ensambla.** Por un lado, **ninguna restricción previa**: *« No forced guardrails, no limitations on what your agents are allowed to help you with. »* Por otro, **un registro firmado de cada acto**: *« Every push, review, approval, and merge is a signed Nostr event »*, con un rastro de **qué agente** produjo un patch y **qué humano** había autorizado a ese agente. De ahí la proyección de cierre: el historial de contribuciones pasa a ser *« more than a set of colored squares on a profile »*, un **historial verificable ligado a una clave**, y Block declara que está **explorando *« agent trust protocols informed by past behavior »***. **La confianza se desplaza de la autorización *a priori* a la prueba *a posteriori*.** El marco asociado es explícito: *« A terminal gives an agent somewhere to execute commands and change files, but it does not give it a persistent place in the network. Buzz does. »*

**Salvedades.** **Sin cifras, sin enlaces salientes, sin especificación** en ningún lugar del texto; **la CI y las notas de versión se prometen pero están ausentes del inventario**; Projects se encuentra bajo la **pestaña Experiments**, y la publicación se descalifica a sí misma seis veces — *« Buzz is still in beta and Buzz Projects is still under experiments, so treat it accordingly. »*

## GrapheDeConnaissance

- Thomas Petersen —travaille_chez→ Block (ORGANISATION, 0.97)
- Block —publie→ Buzz Projects (TECHNOLOGIE, 0.98)
- Buzz Projects —fait_partie_de→ Buzz (TECHNOLOGIE, 0.98)
- Buzz Projects —est_instance_de→ forge logicielle souveraine (CONCEPT, 0.93)
- Buzz Projects —utilise→ Nostr (TECHNOLOGIE, 0.96)
- Buzz Projects —utilise→ Git (TECHNOLOGIE, 0.97)
- Buzz Projects —utilise→ Smart HTTP (TECHNOLOGIE, 0.95)
- Buzz Projects —observé_dans→ Buzz Desktop (TECHNOLOGIE, 0.94)
- clé Nostr —permet→ authentification Git par clé Nostr (CONCEPT, 0.94)
- Buzz Projects —résout→ fragmentation de l'outillage de développement (CONCEPT, 0.9)
- Buzz Projects —réduit→ reconstruction a posteriori du contexte (CONCEPT, 0.9)
- Buzz Projects —permet→ historique de contribution vérifiable (CONCEPT, 0.93)
- historique de contribution vérifiable —est_basé_sur→ événement Nostr signé (CONCEPT, 0.95)
- protocoles de confiance des agents —est_basé_sur→ historique de contribution vérifiable (CONCEPT, 0.88)
- Block —affirme_que→ "we are already exploring ideas around agent trust protocols informed by past behavior" (CITATION, 0.96)
- Thomas Petersen —affirme_que→ "Coding agents are the terminal for your computer. Buzz is the terminal for your network." (CITATION, 0.98)
- Thomas Petersen —affirme_que→ "No forced guardrails, no limitations on what your agents are allowed to help you with." (CITATION, 0.97)
- Thomas Petersen —affirme_que→ "A terminal gives an agent somewhere to execute commands and change files, but it does not give it a persistent place in the network." (CITATION, 0.97)
- Thomas Petersen —affirme_que→ « la clé Nostr qui signe les messages signe aussi les pushes Git, sans compte ni jeton supplémentaire » (AFFIRMATION, 0.96)
- Thomas Petersen —prédit→ « l'historique de contribution deviendra un historique vérifiable attaché à la clé du contributeur, portable entre projets et entre réseaux » (AFFIRMATION, 0.9)
- Thomas Petersen —affirme_que→ « des agents ont compris un contexte que des humains n'avaient pas et ont réorienté des directions improductives » (AFFIRMATION, 0.88)
- Buzz Projects —s_applique_à→ souveraineté organisationnelle (CONCEPT, 0.9)
- Buzz Projects —concurrence→ GitHub (TECHNOLOGIE, 0.86)
- Buzz Projects —s_oppose_à→ autorisation ex ante des agents (CONCEPT, 0.85)
- souveraineté organisationnelle —s_applique_à→ relais Buzz (TECHNOLOGIE, 0.88)
- Buzz —affine→ forge logicielle souveraine (CONCEPT, 0.84)

---
Canonical: https://www.thekb.eu/es/fiches/petersen-block-buzz-projects-forge-souveraine-2026-08-18/