Hva er Beaker Browser og hvorfor snakker folk fortsatt om det

Internett slik vi kjenner det er bygget på klient-tjener-arkitektur. Du skriver inn en adresse, nettleseren går til en tjener et sted i et AWS- eller Cloudflare-datasenter, henter HTML-en og viser siden. Hvis tjeneren går ned, er nettstedet borte. I 2016 foreslo et lite team i Blue Link Labs ledet av Paul Frazee et alternativ: hva om hver bruker ble sin egen tjener?

Slik ble Beaker Browser til, en eksperimentell nettleser basert på Electron og Chromium som brukte Hypercore-protokollen (opprinnelig Dat) for publisering av innhold via peer-to-peer. Ingen backend, ingen hosting: du oppretter et nettsted rett i nettleseren, og andre brukere kobler seg direkte til datamaskinen din.

Prosjektet ble arkivert i desember 2022, men ideene lever videre. Paul Frazee ble CTO i Bluesky, og selve Hypercore-protokollen fortsetter å utvikle seg. Nedenfor finner du hvordan Beaker fungerte under panseret, hvilke P2P-API-er webutviklere hadde tilgang til, og hva som kan erstatte det i dag. Hvis du bygger noe på det desentraliserte nettet, vil disse erfaringene spare deg for uker med prøving og feiling.

💡 Kort oversikt:

• Installer Beaker fra GitHub-utgivelser for Windows, macOS eller Linux. Binære bygg er fortsatt tilgjengelige, ingen separat hosting nødvendig.

• Klikk «Opprett nytt nettsted» så genererer nettleseren et nettsted med en hyper://-adresse rett på datamaskinen din. Ingen DNS, nginx eller distribusjon.

• Rediger filer i den innebygde kodeeditoren og Hyperdrive, del hyper://-adressen med en annen Beaker-bruker, så kobler de seg direkte til deg.

• Prosjektet ble lagt ned i 2022: nettverket er nesten tomt. For fungerende eksperimenter med Hypercore, sjekk ut Agregore og Peersky Browser.

Hvordan Beaker Browser fant opp nettet på nytt

Beaker var ikke bare en Chromium-innpakning med torrent-støtte. Det var en fullverdig nettleser som la til et nytt lag på nettplattformen: muligheten til å lese og skrive filer direkte til et peer-to-peer-nettverk.

Når du besøkte et nettsted med hyper://-protokollen, lastet Beaker filene fra datamaskinene til andre brukere som hadde besøkt det nettstedet. Etter nedlasting begynte du selv å seede filene, enten midlertidig mens siden var åpen, eller permanent hvis du aktiverte seeding. Det lignet på BitTorrent, men bygget rett inn i nettleseren og knyttet til nettadresser.

Seks funksjoner som gjorde Beaker verdt å installere

Umiddelbar publisering av nettsteder. Du klikket «Opprett nytt nettsted» og Beaker genererte et nettsted med en hyper://-adresse. Nettstedet var umiddelbart tilgjengelig på nettverket; alle med Beaker kunne åpne det hvis de kjente adressen. Ingen DNS-konfigurasjon, nginx eller distribusjon.

Samarbeidsbasert hosting. Jo flere besøkende som kom til et P2P-nettsted, desto raskere lastet det, fordi hver besøkende bidro til å distribuere innholdet. Dette reduserte belastningen på forfatteren: ingen kraftig tjener var nødvendig under trafikktopper, nettverket skalerte seg selv.

P2P-applikasjoner med webteknologi. Beaker tilbød beaker.hyperdrive JavaScript-API-et for lesing og skriving til et peer-to-peer-filsystem. Dette betydde at en webapplikasjon kunne lagre data ikke på en tjener, men i et desentralisert nettverk, og brukerne kontrollerte sine egne filer.

Hyperdrive-filsystemet. Hvert nettsted i Beaker var ikke bare et sett med sider, men et fullverdig filsystem med versjonering. Du kunne bla gjennom nettstedstrukturen som i en filbehandler, se endringshistorikken og til og med forke andres prosjekter, likt GitHub men for hele nettet.

Innebygd terminal. Beaker inkluderte Webterm, et kommandolinje-miljø rett i nettleseren. Utviklere kunne kjøre skript, administrere filer og samhandle med API-er uten å forlate nettleservinduet.

Kildekodeeditor. Den integrerte editoren lot deg redigere nettstedets HTML, CSS og JavaScript og se resultatet umiddelbart, side om side med den åpne siden. En idé som ligner moderne nettbaserte IDE-er, men for det desentraliserte nettet.

Arbeid med Hypercore-API-et: kodeeksempler

Beaker la til et beaker-navnerom på det globale window-objektet med flere sentrale API-er. La oss bryte ned de viktigste; all kode er verifisert mot prosjektdokumentasjonen.

Arbeid med Hyperdrive-filsystemet

beaker.hyperdrive-API-et ga direkte tilgang til P2P-nettstedsfiler. Slik så det ut å opprette en drive, skrive og lese:

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')

Metodene er intuitive og ligner på Node.js sin fs-modul: writeFile, readFile, stat, unlink, readdir. Forskjellen er at data ikke skrives til lokal disk, men til peer-to-peer-nettverket, og enhver annen bruker med tilgang til denne driven kan lese dem.

Spørring mot filsystemet

beaker.hyperdrive.query-API-et tillot søk etter filer etter mønster på tvers av flere nettsteder samtidig. Dette åpnet døren for desentraliserte feeder, søkemotorer og sosiale nettverk uten en sentral server:

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
}

Ett kall, og du får en tidssortert liste over innlegg fra mikrobloggene til alle nettsteder i sites-arrayen. Ingen API-nøkler, ingen OAuth, ingen serverinfrastruktur.

Peer-to-peer-meldinger

beaker.peersockets-API-et ga direkte kommunikasjon mellom nettstedsbrukere, likt WebSocket, men kjørende over Hypercore-nettverket:

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
}

Dette API-et muliggjorde bygging av desentraliserte chatter, samarbeidsredigeringsverktøy og sanntidsapplikasjoner der meldinger går direkte fra bruker til bruker uten en mellomliggende server.

Hvorfor prosjektet ble lagt ned: tre lærdommer fra Beaker Browser

Den 27. desember 2022 ble Beaker-repositoriet offisielt arkivert med en melding fra Paul Frazee: «Tiden er kommet.» Han gikk til Bluesky, et desentralisert sosialt nettverk der AT-protokollen løser lignende problemer, men på et annet nivå.

Det var flere grunner til nedleggelsen. For det første beveget P2P-nettet seg aldri forbi eksperimentstadiet. Den gjennomsnittlige brukeren er ikke klar for å kjøre en nettleser som ikke støtter utvidelser, ikke synkroniserer bokmerker og ikke fungerer med kjente nettsteder uten forbehold. For det andre viste kaldstartproblemet for et peer-to-peer-nettverk seg å være brutalt: hvis nettstedsforfatteren er frakoblet og andre besøkende ikke deler, er nettstedet utilgjengelig. For det tredje viste Chromium seg å være et for tungt fundament for en nisjenettleser: å vedlikeholde en fork med egendefinerte API-er krevde ressurser som et team på tre personer ikke hadde.

Men lærdommene fra Beaker er mer verdifulle enn selve nettleseren. Prosjektet demonstrerte at en nettleser kan være ikke bare et vindu inn i nettet, men et fullverdig utviklingsmiljø. At hyper:// som protokoll har en rett til å eksistere. Og at desentraliserte API-er (beaker.hyperdrive, beaker.peersockets) kan være like praktiske som fetch eller localStorage.

Video: Beaker Browser i aksjon

Se en demonstrasjon av Beaker av Paul Frazee, et opptak fra 2017 der han viser hvordan man oppretter et P2P-nettsted i sanntid:

På 5 minutter forklarer videoen tydeligere enn noen ord hvordan øyeblikkelig publisering fungerte og hvorfor ideen var kraftfull.

Hva som kom etterpå: Agregore og andre P2P-nettlesere

Ånden fra Beaker døde ikke. I dag viderefører flere prosjekter ideen om en nettleser for det desentraliserte nettet:

Agregore Browser er en minimalistisk nettleser for det distribuerte nettet, med støtte for IPFS, Hypercore og BitTorrent-protokoller ut av esken. I motsetning til Beaker drar ikke Agregore med seg hele Chromium, men er bygget på lettvekts Electron med fokus på P2P-protokoller. Utvidelser fra nettbutikker støttes, og HTTP-nettsteder fungerer som vanlig. Prosjektet har over 900 stjerner på GitHub og oppdateres aktivt.

Peersky Browser er en annen eksperimentell P2P-nettleser med støtte for IPFS, Hypercore og Web3. Peersky legger til sitt eget sett med P2P-applikasjoner (peersky://p2p/) og fokuserer på integrasjon med on-chain data. Prosjektet er yngre enn Agregore, men utvikler seg i samme retning: nettleseren som en plattform for det desentraliserte nettet.

Selve Hypercore-protokollen lever videre uavhengig av noen nettleser: den driver Keet (P2P-videosamtaler fra protokollskaperne) og andre desentraliserte applikasjoner.

⁉️🤔 Ofte stilte spørsmål

Kan du laste ned og kjøre Beaker Browser nå?

Binære bygg er fortsatt tilgjengelige på GitHub releases-siden for Windows, macOS og Linux. Nettleseren vil starte, men P2P-nettverket er praktisk talt tomt: de fleste noder er offline, og nettsteder er utilgjengelige. For eksperimenter med Hypercore-protokollen bør du heller se på Agregore eller Keet.

Ja, installasjonsfilene ligger fortsatt på GitHub Releases. Men det er ingen praktisk nytte i å installere den i dag: Beaker-nettverket er dødt, dokumentasjonen på docs.beakerbrowser.com er utilgjengelig, og prosjektet har ikke mottatt sikkerhetsoppdateringer siden 2022. For å forstå konseptet er kildekoden på GitHub og videodemonstrasjoner tilstrekkelig.

Hvordan var Beaker forskjellig fra en vanlig nettleser med en torrent-utvidelse?

Beaker var en komplett plattform, ikke et tillegg. En torrent-utvidelse laster bare ned filer, mens Beaker ga nettsteder et JavaScript-API for å lese, skrive, søke i filsystemet og sende direktemeldinger mellom brukere. Alt dette fungerte som en del av nettplattformen, ikke som en ekstern plugin.

En vanlig nettleser med en torrent-klient lar deg laste ned en fil via en magnetlenke. Beaker gikk lenger: et nettsted på hyper:// kunne søke etter innhold på andre nettsteder ved hjelp av beaker.hyperdrive.query(), og utveksle meldinger med besøkende ved hjelp av beaker.peersockets. Dette er et annet integrasjonsnivå: P2P var ikke en nettleserfunksjon, men selve grunnlaget for nettplattformen.

Fungerte Beaker med vanlige HTTP-nettsteder?

Ja, fullt ut. Beaker var bygget på Chromium og åpnet alle HTTP/HTTPS-nettsteder korrekt. Problemet var det motsatte: vanlige nettlesere støttet ikke hyper://-protokollen, så P2P-nettsteder var usynlige for 99,9% av internettbrukerne. Dette var en av grunnene til at prosjektet ikke slo an.

Kompatibiliteten var enveis. Du kunne bruke Beaker som en vanlig nettleser for hele nettet, men P2P-nettstedet du opprettet var bare synlig for andre Beaker-brukere. Masseadopsjon krevde enten støtte for hyper:// i Chrome og Firefox, eller gatewayer som Hashbase som oversatte P2P-nettsteder til HTTP. Ingen av delene skjedde i tilstrekkelig skala.

Hva skjedde med Paul Frazee og Blue Link Labs-teamet?

Paul Frazee ble CTO i Bluesky, et desentralisert sosialt nettverk bygget på AT Protocol. I et innlegg på Bluesky forklarer han at Beaker-erfaringen direkte påvirket arkitekturen til AT Protocol. Blue Link Labs opphørte å eksistere. Den andre nøkkelpersonen i prosjektet, Tara Vancil, skrev et rørende innlegg «A Fond Farewell to Beaker» om prosjektets opp- og nedturer.

Teknisk sett forlot ikke Frazee desentralisering, men beveget seg til et annet nivå. I stedet for en nettleser for P2P-nettet bygger han en protokoll for et desentralisert sosialt nettverk. AT Protocol i Bluesky løser mange problemer som felte Beaker: en føderert modell i stedet for rent peer-to-peer, tydelig skille mellom servere og klienter, støtte for skalering.

Er det noe poeng i å studere Beaker i dag?

Som kodebase, ja. Kildekoden på GitHub viser hvordan man integrerer en P2P-protokoll i en Electron-applikasjon, hvordan man designer et API for et desentralisert filsystem, og hvordan man bygger nettleserutvidelser med egendefinerte protokoller. Som produkt, nei, men som et læringsprosjekt om desentraliserte teknologier, absolutt.

Beaker-kildekoden representerer 6 752 stjerner på GitHub og dusinvis av repositorier med eksperimenter rundt Hypercore-protokollen. For en utvikler som er interessert i P2P-teknologier, er dette en skattekiste av arkitektoniske beslutninger: fra håndtering av egendefinerte protokoller i Electron til bygging av append-only-logger basert på Hypercore.

Er det verdt å se tilbake på Beaker i 2026

Beaker Browser ble ikke mainstream. Men den viste at en alternativ nettmodell er mulig: en modell der brukeren ikke er skilt fra serveren av en stabel med CDN-er, lastbalanserere og API-gatewayer, men selv er en node i nettverket.

Beakers ideer migrerte til Bluesky, Hypercore-protokollen lever videre i Keet og andre prosjekter, og Agregore Browser fortsetter eksperimentet med en flerprotokolls P2P-nettleser i dag. Hvis du er webutvikler og vil forstå hvor den desentraliserte webben er på vei, kan du begynne med Beakers kildekode på GitHub og den aktive Agregore.

Eksperimentet lyktes ikke, men selve ideen viste seg å være smittsom. Og det er kanskje viktigere enn markedssuksess.