Cos'è Beaker Browser e perché se ne parla ancora

Internet come la conosciamo è costruita su un'architettura client-server. Digiti un indirizzo, il browser va su un server da qualche parte in un data center AWS o Cloudflare, recupera l'HTML e visualizza la pagina. Se il server va giù, il sito sparisce. Nel 2016, un piccolo team di Blue Link Labs guidato da Paul Frazee propose un'alternativa: e se ogni utente diventasse il proprio server?

È così che è nato Beaker Browser, un browser sperimentale basato su Electron e Chromium che utilizzava il protocollo Hypercore (originariamente Dat) per la pubblicazione di contenuti peer-to-peer. Nessun backend, nessun hosting: crei un sito direttamente nel browser e gli altri utenti si connettono direttamente al tuo computer.

Il progetto è stato archiviato a dicembre 2022, ma le sue idee sopravvivono. Paul Frazee è diventato CTO di Bluesky e il protocollo Hypercore stesso continua a evolversi. Di seguito troverai come funzionava Beaker sotto il cofano, a quali API P2P avevano accesso gli sviluppatori web e cosa può sostituirlo oggi. Se stai costruendo qualcosa sul web decentralizzato, queste lezioni ti faranno risparmiare settimane di tentativi ed errori.

💡 Panoramica rapida:

• Installa Beaker dalle release di GitHub per Windows, macOS o Linux. Le build binarie sono ancora disponibili, non è richiesto hosting separato.

• Clicca "Create New Site" e il browser genera un sito con un indirizzo hyper:// direttamente sul tuo computer. Niente DNS, nginx o deployment.

• Modifica i file nell'editor di codice integrato e in Hyperdrive, condividi l'indirizzo hyper:// con un altro utente Beaker e questo si connette direttamente a te.

• Il progetto è stato chiuso nel 2022: la rete è quasi vuota. Per esperimenti funzionanti con Hypercore, dai un'occhiata ad Agregore e Peersky Browser.

Come Beaker Browser ha reinventato il web

Beaker non era solo un wrapper di Chromium con supporto torrent. Era un browser a tutti gli effetti che aggiungeva un nuovo livello alla piattaforma web: la capacità di leggere e scrivere file direttamente su una rete peer-to-peer.

Quando visitavi un sito con il protocollo hyper://, Beaker caricava i suoi file dai computer di altri utenti che avevano visitato quel sito. Dopo il download, iniziavi tu stesso a condividere i file, temporaneamente mentre la pagina era aperta o permanentemente se abilitavi la condivisione. Era simile a BitTorrent, ma integrato direttamente nel browser e legato agli indirizzi web.

Sei funzionalità che rendevano Beaker degno di essere installato

Pubblicazione istantanea del sito. Cliccavi "Create New Site" e Beaker generava un sito con un indirizzo hyper://. Il sito era immediatamente disponibile sulla rete; chiunque avesse Beaker poteva aprirlo se conosceva l'indirizzo. Nessuna configurazione DNS, nginx o deployment.

Hosting collaborativo. Più visitatori arrivavano su un sito P2P, più velocemente si caricava, perché ogni visitatore aiutava a distribuire il contenuto. Questo riduceva il carico sull'autore: non serviva un server potente durante i picchi di traffico, la rete si scalava da sola.

Applicazioni P2P con tecnologie web. Beaker forniva l'API JavaScript beaker.hyperdrive per leggere e scrivere su un file system peer-to-peer. Questo significava che un'applicazione web poteva memorizzare i dati non su un server ma in una rete decentralizzata e gli utenti controllavano i propri file.

Il file system Hyperdrive. Ogni sito in Beaker non era solo un insieme di pagine ma un file system a tutti gli effetti con versionamento. Potevi esplorare la struttura del sito come in un file manager, vedere la cronologia delle modifiche e persino fare il fork dei progetti di altre persone, simile a GitHub ma per l'intero web.

Terminale integrato. Beaker includeva Webterm, un ambiente a riga di comando direttamente nel browser. Gli sviluppatori potevano eseguire script, gestire file e interagire con le API senza lasciare la finestra del browser.

Editor di codice sorgente. L'editor integrato permetteva di modificare HTML, CSS e JavaScript del sito e vedere il risultato immediatamente, fianco a fianco con la pagina aperta. Un'idea simile ai moderni IDE online, ma per il web decentralizzato.

Lavorare con l'API Hypercore: esempi di codice

Beaker aggiungeva un namespace beaker all'oggetto globale window con diverse API chiave. Analizziamo le principali; tutto il codice è stato verificato rispetto alla documentazione del progetto.

Lavorare con il file system Hyperdrive

L'API beaker.hyperdrive forniva accesso diretto ai file dei siti P2P. Ecco come si presentavano la creazione di un drive, la scrittura e la lettura:

1
const drive = await beaker.hyperdrive.createDrive()
2
 
3
await drive.readdir('/')
4
await drive.writeFile('/hello.md', '# Hello, P2P web!')
5
 
6
const stat = await drive.stat('/hello.md')
7
console.log('Size:', stat.size, 'bytes')
8
console.log('Modified:', stat.mtime)
9
 
10
const content = await drive.readFile('/hello.md', 'utf8')
11
console.log(content) // '# Hello, P2P web!'
12
 
13
await drive.unlink('/hello.md')

I metodi sono intuitivi e simili al modulo fs di Node.js: writeFile, readFile, stat, unlink, readdir. La differenza è che i dati non vengono scritti sul disco locale ma sulla rete peer-to-peer, e qualsiasi altro utente con accesso a questo drive può leggerli.

Interrogare il file system

L'API beaker.hyperdrive.query permetteva di cercare file per pattern su più siti simultaneamente. Questo apriva la porta a feed decentralizzati, motori di ricerca e social network senza un server centrale:

1
async function readSocialFeed(sites) {
2
  return beaker.hyperdrive.query({
3
    path: '/microblog/*',
4
    drive: sites.map(site => site.url),
5
    sort: 'ctime',
6
  })
7
}

Una sola chiamata e si ottiene una lista di post ordinata per data dai microblog di tutti i siti nell'array sites. Nessuna API key, nessun OAuth, nessuna infrastruttura server.

Messaggi peer-to-peer

L'API beaker.peersockets forniva comunicazione diretta tra gli utenti del sito, simile a WebSocket ma in esecuzione sulla rete Hypercore:

1
const topic = beaker.peersockets.join('chat')
2
 
3
topic.addEventListener('message', (e) => {
4
  const message = new TextDecoder().decode(e.message)
5
  console.log(e.peerId, 'says:', message)
6
})
7
 
8
function sendToPeer(peerId, message) {
9
  const encoded = new TextEncoder('utf-8').encode(message)
10
  topic.send(peerId, encoded)
11
}

Questa API permetteva di costruire chat decentralizzate, editor collaborativi e applicazioni in tempo reale dove i messaggi vanno direttamente da utente a utente senza un server intermediario.

Perché il progetto è stato chiuso: tre lezioni da Beaker Browser

Il 27 dicembre 2022, il repository di Beaker è stato ufficialmente archiviato con una nota di Paul Frazee: «È arrivato il momento». Si è spostato su Bluesky, un social network decentralizzato dove l'AT Protocol risolve problemi simili ma a un livello diverso.

C'erano diverse ragioni per la chiusura. Primo, il web P2P non ha mai superato la fase di sperimentazione. L'utente medio non è pronto a usare un browser che non supporta le estensioni, non sincronizza i segnalibri e non funziona con i siti abituali senza limitazioni. Secondo, il problema del cold start per una rete peer-to-peer si è rivelato duro: se l'autore del sito è offline e gli altri visitatori non stanno facendo seeding, il sito non è disponibile. Terzo, Chromium si è rivelato una base troppo pesante per un browser di nicchia: mantenere un fork con API personalizzate richiedeva risorse che un team di tre persone non aveva.

Ma le lezioni di Beaker sono più preziose del browser stesso. Il progetto ha dimostrato che un browser può essere non solo una finestra sul web ma un vero e proprio ambiente di sviluppo. Che hyper:// come protocollo ha diritto di esistere. E che le API decentralizzate (beaker.hyperdrive, beaker.peersockets) possono essere comode quanto fetch o localStorage.

Video: Beaker Browser in azione

Guarda una dimostrazione di Beaker di Paul Frazee, una registrazione del 2017 in cui mostra la creazione di un sito P2P in tempo reale:

In 5 minuti, il video spiega più chiaramente di qualsiasi parola come funzionava la pubblicazione istantanea e perché l'idea era potente.

Cosa è successo dopo: Agregore e altri browser P2P

Lo spirito di Beaker non è morto. Oggi diversi progetti portano avanti l'idea di un browser per il web decentralizzato:

Agregore Browser è un browser minimalista per il web distribuito, con supporto nativo per i protocolli IPFS, Hypercore e BitTorrent. A differenza di Beaker, Agregore non si trascina dietro l'intero Chromium ma è costruito su Electron in versione leggera, con un focus sui protocolli P2P. Le estensioni del web store sono supportate, i siti HTTP funzionano come di consueto. Il progetto ha oltre 900 stelle su GitHub ed è aggiornato attivamente.

Peersky Browser è un altro browser P2P sperimentale con supporto per IPFS, Hypercore e Web3. Peersky aggiunge un proprio set di applicazioni P2P (peersky://p2p/) e si concentra sull'integrazione con i dati on-chain. Il progetto è più giovane di Agregore ma si sta sviluppando nella stessa direzione: il browser come piattaforma per il web decentralizzato.

Il protocollo Hypercore stesso continua a vivere indipendentemente da qualsiasi browser: alimenta Keet (videochiamate P2P dai creatori del protocollo) e altre applicazioni decentralizzate.

⁉️🤔 Domande frequenti

Si può scaricare ed eseguire Beaker Browser adesso?

Le build binarie sono ancora disponibili sulla pagina delle release di GitHub per Windows, macOS e Linux. Il browser si avvia, ma la rete P2P è praticamente vuota: la maggior parte dei peer è offline, i siti non sono raggiungibili. Per esperimenti con il protocollo Hypercore, conviene orientarsi su Agregore o Keet.

Sì, i file di installazione sono ancora su GitHub Releases. Ma non ha alcuna utilità pratica installarlo oggi: la rete Beaker è morta, la documentazione su docs.beakerbrowser.com non è disponibile e il progetto non riceve aggiornamenti di sicurezza dal 2022. Per comprendere il concetto, il codice sorgente su GitHub e le dimostrazioni video sono sufficienti.

In cosa Beaker era diverso da un normale browser con un'estensione torrent?

Beaker era una piattaforma completa, non un componente aggiuntivo. Un'estensione torrent si limita a scaricare file, mentre Beaker forniva ai siti un'API JavaScript per leggere, scrivere, cercare nel file system e scambiare messaggi diretti tra utenti. Tutto questo funzionava come parte della piattaforma web, non come plugin esterno.

Un normale browser con un client torrent permette di scaricare un file tramite un link magnet. Beaker andava oltre: un sito su hyper:// poteva cercare contenuti su altri siti usando beaker.hyperdrive.query() e scambiare messaggi con i visitatori tramite beaker.peersockets. Questo è un livello di integrazione diverso: il P2P non era una funzionalità del browser, ma il fondamento della piattaforma web.

Beaker funzionava con i normali siti HTTP?

Sì, pienamente. Beaker era costruito su Chromium e apriva correttamente qualsiasi sito HTTP/HTTPS. Il problema era l'inverso: i browser normali non supportavano il protocollo hyper://, quindi i siti P2P erano invisibili al 99,9% degli utenti di internet. Questa è stata una delle ragioni per cui il progetto non ha preso piede.

La compatibilità era a senso unico. Si poteva usare Beaker come un normale browser per l'intero web, ma il sito P2P che si creava era visibile solo agli altri utenti Beaker. L'adozione di massa richiedeva o il supporto per hyper:// in Chrome e Firefox, oppure gateway come Hashbase che traducevano i siti P2P in HTTP. Nessuna delle due cose è avvenuta su scala sufficiente.

Cosa è successo a Paul Frazee e al team di Blue Link Labs?

Paul Frazee è diventato CTO di Bluesky, un social network decentralizzato costruito sull'AT Protocol. In un post su Bluesky, spiega che l'esperienza di Beaker ha influenzato direttamente l'architettura dell'AT Protocol. Blue Link Labs ha cessato di esistere. La seconda figura chiave del progetto, Tara Vancil, ha scritto un toccante post "A Fond Farewell to Beaker" sugli alti e bassi del progetto.

Tecnicamente, Frazee non ha abbandonato la decentralizzazione, ma si è spostato a un livello diverso. Invece di un browser per il web P2P, sta costruendo un protocollo per un social network decentralizzato. L'AT Protocol in Bluesky risolve molti problemi che avevano fatto inciampare Beaker: un modello federato invece che puramente peer-to-peer, una chiara separazione tra server e client, supporto per la scalabilità.

Ha senso studiare Beaker oggi?

Come codebase, sì. Il codice sorgente su GitHub mostra come integrare un protocollo P2P in un'applicazione Electron, come progettare un'API per un file system decentralizzato e come costruire estensioni del browser con protocolli personalizzati. Come prodotto, no, ma come progetto formativo sulle tecnologie decentralizzate, assolutamente sì.

Il codice sorgente di Beaker rappresenta 6.752 stelle su GitHub e decine di repository con esperimenti attorno al protocollo Hypercore. Per uno sviluppatore interessato alle tecnologie P2P, è un tesoro di decisioni architetturali: dalla gestione di protocolli personalizzati in Electron alla costruzione di log append-only basati su Hypercore.

Vale la pena guardare indietro a Beaker nel 2026

Beaker Browser non è diventato mainstream. Ma ha dimostrato che un modello di web alternativo è possibile: un modello in cui l'utente non è separato dal server da una pila di CDN, load balancer e gateway API, ma è esso stesso un nodo della rete.

Le idee di Beaker sono migrate su Bluesky, il protocollo Hypercore sopravvive in Keet e in altri progetti, e Agregore Browser prosegue ancora oggi l'esperimento di un browser P2P multi-protocollo. Se sei uno sviluppatore web e vuoi capire dove sta andando il web decentralizzato, parti dal codice sorgente di Beaker su GitHub e dal progetto attivo Agregore.

L'esperimento non ha avuto successo, ma l'idea in sé si è rivelata contagiosa. E questo è forse più importante del successo di mercato.