Jack Dorsey annuncia la versione 1.0 di Buzz, il workspace open source basato su Nostr

• Cos’è Nostr e perché Block lo ha scelto
• Come Buzz utilizza concretamente Nostr
• Self-hosting e opzioni di deployment
• È davvero decentralizzato?

Buzz, il workspace open source lanciato da Block (la società di Jack Dorsey) nel luglio 2026 e arrivato alla versione 1.0 a novembre, si presenta come un ambiente di collaborazione nativo per team misti di umani e agenti AI. Non è un semplice chat tool con bot attaccati: umani e agenti condividono gli stessi canali, lo stesso contesto e la stessa traccia di audit. Al centro di questa architettura c’è il protocollo Nostr.

§Cos’è Nostr e perché Block lo ha scelto

Nostr (Notes and Other Stuff Transmitted by Relays) è un protocollo aperto e minimalista basato su eventi firmaticriptograficamente. Ogni partecipante possiede una coppia di chiavi secp256k1: la chiave pubblica è l’identità, la firma Schnorr garantisce autenticità e integrità. I client si collegano a uno o più relay (server) via WebSocket, pubblicano eventi firmati e si abbonano a filtri. Non esiste un server centrale obbligatorio: chiunque può gestire un relay, e le identità sono portabili indipendentemente dalla piattaforma.

Block ha scelto Nostr soprattutto per risolvere il problema dell’identità in un contesto multi-agente. In strumenti tradizionali gli agenti spesso ereditano le credenziali di un umano o usano account di servizio condivisi. In Buzz ogni agente ha la propria keypair. L’umano proprietario firma un’autorizzazione a scope limitato; l’agente firma poi le proprie azioni con la propria chiave. L’autorizzazione non cancella la paternità: resta traccia di chi ha agito e di chi ha autorizzato. Se la chiave di un agente viene compromessa, si può revocare solo quell’agente senza toccare l’identità umana.

§Come Buzz utilizza concretamente Nostr

Buzz non è un client Nostr generico: il cuore del sistema è un relay Nostr specializzato (scritto in Rust).

• Ogni azione rilevante diventa un evento Nostr firmato (formato NIP-01): messaggi di chat, reazioni, passi di workflow, eventi git (patch, review, merge), aggiornamenti di canvas, presenza, ecc.
• Il kind (numero intero) distingue il tipo di evento. Buzz usa sia kind standard Nostr sia range custom (soprattutto 40000+) per le funzionalità enterprise. Aggiungere una nuova funzionalità significa definire un nuovo kind: i client esistenti non si rompono.
• Il relay è la singola fonte di verità. Client (app desktop Tauri/React, web, CLI degli agenti) si collegano via WebSocket. Non c’è scambio peer-to-peer di eventi, né gossip automatico tra relay, né replica globale incorporata nel design di base di una community.
• Una community (il workspace) è legata all’URL/dominio del relay. Nel setup self-hosted tipico un relay = una community. Nelle installazioni multi-tenant di Block o di operatori terzi, il backend risolve la community dal host della connessione.
• Vengono sfruttati NIP specifici: NIP-42 per l’autenticazione, NIP-29 per i gruppi/canali, NIP-34 per l’attività git, Blossom per i media, ecc.
• Gli eventi formano un log append-only con traccia di audit (hash-chain) unificata: chat, codice, decisioni e automazioni condividono lo stesso indice di ricerca e la stessa storia verificabile.

Il risultato pratico è che una feature branch può diventare un canale, le discussioni, le patch, i risultati CI e le approvazioni di merge convivono nello stesso thread firmato, e gli agenti possono partecipare come membri di pari grado (non come bot esterni).

§Self-hosting e opzioni di deployment

Buzz è Apache-2.0. Si può:

• usare il relay hostato da Block su buzz.xyz;
• eseguire il proprio relay (binario Rust + Postgres + Redis + storage S3-compatibile).

Self-hosting significa che messaggi, media, membership e audit log restano su infrastruttura controllata dall’organizzazione. Le chiavi restano dell’utente/agente. Se il servizio hostato sparisse, le identità e la storia firmata restano verificabili e i repository git possono essere ripristinati altrove.

§È davvero decentralizzato?

Qui serve distinzione.

Sì, a livello di protocollo e identità:

• Identità criptografiche portabili e indipendenti dalla piattaforma.
• Eventi firmati e verificabili da chiunque.
• Codice open source, possibilità di self-hosting totale.
• Nessun lock-in sulle chiavi o sulla storia firmata.
• Compatibilità potenziale con l’ecosistema Nostr più ampio (client terzi possono connettersi al relay Buzz tramite NIP-29/NIP-42).

Parzialmente, a livello di network e di singolo workspace:

• Una community Buzz dipende da un relay specifico come fonte di verità. Non c’è federazione automatica né replica multi-relay nativa per mantenere coerenza di ricerca, workflow, membership e audit all’interno di un workspace.
• I relay non condividono automaticamente i contenuti tra loro. Un messaggio resta sul relay su cui è stato pubblicato.
• Il client può connettersi a più relay, ma ogni community resta legata al proprio.
• L’architettura privilegia consistenza, performance e funzionalità enterprise (ricerca unificata, automazioni, git hosting, presenza) rispetto a una rete completamente peer-to-peer o multi-relay ridondante.

In sintesi, Buzz è più precisamente self-sovereign e costruito su infrastruttura decentralizzata (Nostr) piuttosto che un sistema pienamente decentralizzato nello stile di una rete sociale Nostr globale multi-relay. Quando si self-hosta si ottiene un alto grado di sovranità: si controllano dati, chiavi e regole. Quando si usa l’istanza hostata da Block, la dipendenza operativa è maggiore, anche se il protocollo e le chiavi restano aperti.

Questa scelta è deliberata. Per un workspace di team (soprattutto con agenti che producono codice e decisioni) avere un log unico, ricercabile e coerente è più importante della massima resilienza multi-relay. La decentralizzazione di Buzz è quindi “a strati”: forte sull’identità e sulla proprietà dei dati, più pragmatica sull’architettura di rete del singolo workspace.

In conclusione, Buzz non è un semplice “Slack + AI” con marketing decentralizzato. L’uso di Nostr è strutturale: identità, eventi, audit e portabilità derivano direttamente dal protocollo. Può essere considerato decentralizzato per quanto riguarda identità, verificabilità e possibilità di self-hosting, ma non è (ancora) un sistema federato o multi-relay nativo per ogni community. È, piuttosto, uno dei primi tentativi concreti di portare i principi di Nostr dentro un ambiente di lavoro produttivo per umani e agenti, privilegiando sovranità e auditabilità rispetto alla decentralizzazione massimale della rete.