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

## Veille

Post di annuncio prodotto di **Block Engineering** firmato da **Thomas Petersen** (*Principal Designer & Builder*), pubblicato il **18 agosto 2026**, ~1.800 parole suddivise in tredici brevi sezioni, che presenta **Buzz Projects** — una **forge software ospitata sul proprio relay**: repository Git, branch, pull request, issue, revisione e merge, progetti multi-repo, un feed di attività, il tutto collegato ai canali di conversazione. Il catenaccio e la tesi del post: *« Coding agents are the terminal for your computer. Buzz is the terminal for your network. »* Tre contributi. **(A) Una dottrina di fiducia fondata sulla prova *ex post* piuttosto che sull'autorizzazione *ex ante***: da un lato *« No forced guardrails, no limitations on what your agents are allowed to help you with »*, dall'altro *« 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 sezione si chiude su una direzione dichiarata — *« we are already exploring ideas around agent trust protocols informed by past behavior »*. **(B) Interoperabilità Git senza strumenti proprietari**: *« 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 che funge da identità unica — *« The same npub that signs your messages signs your pushes. »* **(C) Una distinzione tra superficie di esecuzione e presenza in rete**: *« 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. »* Il post non produce alcuna cifra e non contiene link esterni; si qualifica come preliminare sei volte (*« still very basic »*, *« fairly elementary »*, *« still under experiments »*), e Projects risiede sotto la scheda **Experiments** di 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, forge software, forge software, relay, relay, Nostr, npub, identità portabile, evento firmato, evento Nostr firmato, hosted git, hosted git, Smart HTTP, fetch clone pull push, senza strumenti proprietari, progetto multi-repo, pull request, issue, code review, diff, merge, CI, note di rilascio, feed di attività, scheda Experiments, Buzz Desktop, collegamento progetto-canale, contesto condiviso, il contesto è tutto ciò che serve, storia dei contributi, storia verificabile, reputazione degli agenti, protocolli di fiducia degli agenti, comportamento passato, autorizzazione ex ante, prova ex post, nessun guardrail forzato, sovranità, protocollo aperto, terminale per la tua rete, presenza persistente in rete, frammentazione degli strumenti, beta, sperimentale, 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

**Profilo**: un manifesto di prodotto in forma di visita guidata — ~1.800 parole, tredici brevi sezioni con titoli-slogan, uno screenshot per funzionalità. Pubblico: gli utenti già esistenti di Buzz Desktop (*« If you've used Buzz Desktop recently and happened to click on the Experiments tab… »*) e, implicitamente, chiunque stia valutando un'alternativa a GitHub. Una demo narrata abbinata a una posizione, né un resoconto di design né un benchmark.

**Stile**: la pagina è incorniciata da falsi prompt di shell — `$ cd ~`, `$ find .`, `$ git blame`, `$ cat content.md`, `$ echo "Copyright 2026 Block, Inc."` — il catenaccio annuncia *« Buzz is the terminal for your network »* e l'impaginazione lo mette in scena. I titoli di sezione sono tesi più che descrizioni (*« Context is (almost) all you need »*, *« All conversations lead to projects and back »*, *« Your project, your relay »*, *« Autonomy, sovereignty and the big picture »*); il *« (almost) »* nel primo è l'unica riserva del testo e non viene mai esplicitato. L'autolimitazione è sistematica: sei disclaimer espliciti, incluso un *Disclaimer* nominato nell'ultima riga — *« Buzz is still in beta and Buzz Projects is still under experiments, so treat it accordingly. »* La prosa è scritta rapidamente, con due frasi spezzate nell'originale: una senza soggetto grammaticale (*« 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 »*), l'altra con un verbo troncato (*« new scenarios we have solve »*). Il "noi" del prodotto sostituisce l'"io" dell'ingegnere: *« We believe those things belong together »*, *« we think this distinction will become increasingly important »*.

**Frasi firma**:
- ***« 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 »***

**Stato epistemico**: una dottrina di design illustrata con screenshot, senza alcun dato — non un utente, non un repository, non una durata, non un costo, non un benchmark — e nessun link esterno in tutta la pagina. Citabile come posizione architetturale di Block su cosa dovrebbe essere una forge nell'era degli agenti; non come prova di funzionamento, né come indicazione di adozione.

## Pense-betes

- **Data / fonte**: **18 agosto 2026**, blog di **Block Engineering**, ~1.800 parole, firmato da **Thomas Petersen** (*Principal Designer & Builder*). Nessun link esterno, nessuna cifra.
- **Inquadramento chiave**: Buzz Projects è una forge in cui **la conversazione è un artefatto di prima classe** — i progetti sono collegati ai canali, e *« Instead of reconstructing why something happened after the fact, the history is already there. »* ### Il modello di fiducia: due paragrafi da leggere insieme | Sezione del post | Verbatim | Cosa stabilisce | |---|---|---| | *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. »* | rimozione del vincolo preventivo | | *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. »* | registrazione firmata dell'atto | | stesso paragrafo, chiusura | *« we are already exploring ideas around agent trust protocols informed by past behavior »* | derivare la fiducia dalla storia | La posizione è architetturale: in una rete dove la delega è illimitata, l'autorizzazione *a priori* scala male, la firma no. È la versione "rete" di quanto esposto da [[longwell-block-buzz-workspace-agents-nostr-2026-07-21]] a luglio a livello di identità (*« authorization does not erase authorship »*). Due limiti che il post non affronta: una registrazione *ex post* non impedisce la prima occorrenza di un danno, e una storia firmata dimostra ciò che è stato fatto, non la completezza di ciò che viene mostrato — un registro negativo (PR respinte, regressioni, incidenti) sarebbe necessario per una reputazione, e non viene menzionato. ### Ciò che la firma garantisce, e ciò che non garantisce | Garantito | Non garantito | |---|---| | l'evento è stato effettivamente prodotto da questa chiave | che la chiave abbia prodotto **tutto** ciò che le viene attribuito | | l'integrità di ogni evento isolato | la **completezza** del lotto presentato | | il legame agente autorizzante → essere umano | la **reperibilità** degli eventi al di fuori del relay di origine | Punto architetturale da non attribuire a questo post: il relay è l'unica fonte di verità, senza replica né scambio peer-to-peer. Questo deriva dall'`ARCHITECTURE.md` di Block come consolidato in [[buzz-block-panorama-deep-research-2026-08-12]], non da questo testo, che non ne dice nulla. Conseguenza: la sovranità offerta è un **diritto di uscita**, non una garanzia di disponibilità. ### Interoperabilità Git: l'affermazione più verificabile Verbatim: *« 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. »* Conseguenze: il costo di uscita è basso per costruzione (un `git clone` recupera il codice), e l'identità unica elimina la gestione dei token. Sfumatura da conservare: **solo il codice è standard** — conversazione, revisione, collegamento PR↔canale e storia dei contributi vivono in *event kind* Nostr specifici di Buzz. Un test fattibile in dieci minuti: `clone` poi `push` da un client Git puro contro un relay Buzz, senza la CLI `buzz`. ### Inventario annunciato vs. inventario consegnato Il paragrafo di apertura elenca sei frammenti da riunire; la sezione *« What's next? »* elenca ciò che esiste. | Frammento citato in apertura | Presente nell'inventario del 18 agosto | |---|---| | *« A bug report lands in one tool »* | sì — issue | | *« The discussion happens in another »* | sì — canali collegati al progetto | | *« The fix lives on a branch somewhere else »* | sì — *hosted git*, multi-repo | | *« Review happens in a comment thread attached to a diff »* | sì — PR, revisioni, commenti inline | | *« CI runs in another system »* | **no** — citato tra le promesse, assente dall'inventario | | *« Release notes get written later »* | **no** | Sei frammenti annunciati, quattro consegnati. Non riutilizzare l'elenco "repos, branches, pull requests, issues, CI, or all the related conversations" come inventario delle funzionalità già disponibili. ### Distinzione da riutilizzare: eseguire non equivale a essere presenti | Ciò che un terminale offre a un agente | Ciò che aggiunge la presenza in rete | |---|---| | eseguire, scrivere file | un'**identità stabile** che altri possono indirizzare | | stato locale, effimero | una **storia associata** che sopravvive alla sessione | | agire | **essere ritenuto responsabile** di ciò che è stato fatto | Un quadro utile per confrontare un tool-agent (invocato) con un member-agent (interpellato). Corollario che il post non affronta: una presenza persistente è anche una superficie d'attacco persistente — vedi [[valente-zalewski-beyond-zero-enterprise-security-ai-era-2026-07-20]]. ### "Il contesto è (quasi) tutto ciò che serve" Verbatim: *« The more context we can make available, the better equipped the agents are, the more intelligent the whole network becomes. »* La monotonicità viene affermata senza argomentazione: non si discute né del costo del contesto, né del suo degrado, né della sua selezione, e il *« (almost) »* non viene mai esplicitato. Da confrontare con il budget di token quantificato dalla stessa Block da [[patel-block-buzz-teams-tokens-benchmarks-2026-08-06]]. ### L'unica affermazione di effetto del post *« We've already seen a number of examples where agents understood context humans didn't and helped course correct otherwise unproductive directions. »* Nessun esempio, nessun numero, nessun criterio di successo. Formulazione corretta per il riutilizzo: *« Block riporta, senza documentarli, casi in cui gli agenti hanno corretto direzioni improduttive usando il contesto del canale. »* Fiche da riaprire se Block pubblica questi casi. ### Igiene della citazione 1. Citabile come **intenzione architetturale** di Block; non come prova di funzionamento o di adozione. 2. Riportare sempre la maturità dichiarata: scheda **Experiments**, *« fairly elementary »*, Buzz *« still in beta »*. 3. Distinguere le funzionalità mostrate negli screenshot, quelle inventariate sotto *« What's next? »*, e quelle solo nominate nelle frasi di promessa (CI, note di rilascio). 4. I *« agent trust protocols »* sono una direzione dichiarata, senza schema, senza criterio, senza tempistica.

## RésuméDe400mots

Post di annuncio di **Block Engineering** firmato da **Thomas Petersen** (*Principal Designer & Builder*), pubblicato il **18 agosto 2026**, che presenta **Buzz Projects** — il mattone forge di **Buzz**, lo spazio di lavoro umani+agenti di Block costruito su **Nostr**.

**Il problema enunciato.** *« Software development tools are fragmented in ways the work itself is not. »* La segnalazione di bug sta in uno strumento, la discussione in un altro, la correzione su un branch, la CI altrove, la revisione in un thread di commenti, le note di rilascio ricostruite a posteriori. **La tesi: tutto questo è una sola conversazione, e la storia deve far parte del progetto.**

**Ciò che Projects offre.** Una **forge ospitata sul proprio relay**: repository Git standard accessibili tramite `fetch/clone/pull/push` su **Smart HTTP**, *« with no custom tooling or wrapper CLI required »*; **la clé Nostr come identità unica** — *« the same npub that signs your messages signs your pushes »*, senza token separato né account GitHub; **progetti multi-repo** che possono includere repository non posseduti (*« you just won't have authority over it »*); issue, pull request, diff, commenti inline, revisione e merge; un **feed di attività** a livello di server; e il **collegamento di qualsiasi progetto a un numero qualsiasi di canali**, affinché *« the context around a change doesn't disappear the moment agents start writing code »*. Da un canale, un'issue può essere affidata a un agente oppure si può chiedere all'agente di aprire una PR, che rimanda alla conversazione che l'ha generata; l'agente si rivolge all'essere umano tramite l'**Inbox**.

**La dottrina, in due parti che il post non assembla mai.** Da un lato, **nessun vincolo preventivo**: *« No forced guardrails, no limitations on what your agents are allowed to help you with. »* Dall'altro, **una registrazione firmata di ogni atto**: *« Every push, review, approval, and merge is a signed Nostr event »*, con una traccia di **quale agente** ha prodotto una patch e **quale essere umano** l'aveva autorizzato. Da qui la proiezione conclusiva: la storia dei contributi diventa *« more than a set of colored squares on a profile »*, una **storia verificabile associata a una chiave**, e Block dichiara di **esplorare *« agent trust protocols informed by past behavior »***. **La fiducia si sposta dall'autorizzazione *ex ante* alla prova *ex post*.** L'inquadramento associato è esplicito: *« 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. »*

**Riserve.** **Nessuna cifra, nessun link esterno, nessuna specifica** in tutto il testo; **CI e note di rilascio sono promesse ma assenti dall'inventario**; Projects risiede sotto la **scheda Experiments**, e il post si autosqualifica sei volte — *« 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/it/fiches/petersen-block-buzz-projects-forge-souveraine-2026-08-18/