Vad är Beaker Browser och varför pratar folk fortfarande om det

Internet som vi känner det är byggt på klient-server-arkitektur. Du skriver in en adress, webbläsaren går till en server någonstans i ett AWS- eller Cloudflare-datacenter, hämtar HTML-koden och renderar sidan. Om servern går ner försvinner sajten. 2016 föreslog ett litet team på Blue Link Labs under ledning av Paul Frazee ett alternativ: tänk om varje användare blev sin egen server?

Så föddes Beaker Browser, en experimentell webbläsare baserad på Electron och Chromium som använde Hypercore-protokollet (ursprungligen Dat) för peer-to-peer-publicering av innehåll. Ingen backend, ingen hosting: du skapar en sajt direkt i webbläsaren, och andra användare ansluter direkt till din dator.

Projektet arkiverades i december 2022, men dess idéer lever vidare. Paul Frazee blev CTO på Bluesky, och själva Hypercore-protokollet fortsätter att utvecklas. Nedan får du veta hur Beaker fungerade under huven, vilka P2P-API:er webbutvecklare hade tillgång till och vad som kan ersätta det idag. Om du bygger något på den decentraliserade webben kommer dessa lärdomar att spara dig veckor av trial and error.

💡 Snabb översikt:

• Installera Beaker från GitHub releases för Windows, macOS eller Linux. Binära byggen finns fortfarande tillgängliga, ingen separat hosting krävs.

• Klicka på "Create New Site" så genererar webbläsaren en sajt med en hyper://-adress direkt på din dator. Ingen DNS, nginx eller deployment.

• Redigera filer i den inbyggda kodredigeraren och Hyperdrive, dela hyper://-adressen med en annan Beaker-användare, så ansluter de direkt till dig.

• Projektet lades ner 2022: nätverket är nästan tomt. För fungerande experiment med Hypercore, kolla in Agregore och Peersky Browser.

Hur Beaker Browser återuppfann webben

Beaker var inte bara en Chromium-wrapper med torrentstöd. Det var en fullfjädrad webbläsare som lade till ett nytt lager till webbplattformen: möjligheten att läsa och skriva filer direkt till ett peer-to-peer-nätverk.

När du besökte en sajt med hyper://-protokollet laddade Beaker dess filer från datorerna hos andra användare som hade besökt den sajten. Efter nedladdning började du själv att seeda filerna, antingen tillfälligt medan sidan var öppen eller permanent om du aktiverade seeding. Det liknade BitTorrent, men inbyggt direkt i webbläsaren och knutet till webbadresser.

Sex funktioner som gjorde Beaker värd att installera

Omedelbar sajtpublicering. Du klickade på "Create New Site" och Beaker genererade en sajt med en hyper://-adress. Sajten var omedelbart tillgänglig på nätverket; vem som helst med Beaker kunde öppna den om de kände till adressen. Ingen DNS-konfiguration, nginx eller deployment.

Kollaborativ hosting. Ju fler besökare som kom till en P2P-sajt, desto snabbare laddade den, eftersom varje besökare hjälpte till att distribuera innehållet. Detta minskade belastningen på upphovspersonen: ingen kraftfull server behövdes vid trafiktoppar, nätverket skalade sig självt.

P2P-applikationer med webbteknik. Beaker tillhandahöll JavaScript-API:et beaker.hyperdrive för att läsa och skriva till ett peer-to-peer-filsystem. Det innebar att en webbapplikation kunde lagra data inte på en server utan i ett decentraliserat nätverk, och användarna kontrollerade sina egna filer.

Filsystemet Hyperdrive. Varje sajt i Beaker var inte bara en uppsättning sidor utan ett fullfjädrat filsystem med versionshantering. Du kunde bläddra i sajtstrukturen som i en filhanterare, se ändringshistoriken och till och med forka andras projekt, liknande GitHub men för hela webben.

Inbyggd terminal. Beaker inkluderade Webterm, en kommandoradsmiljö direkt i webbläsaren. Utvecklare kunde köra skript, hantera filer och interagera med API:er utan att lämna webbläsarfönstret.

Källkodsredigerare. Den integrerade redigeraren lät dig redigera sajtens HTML, CSS och JavaScript och se resultatet omedelbart, sida vid sida med den öppna sidan. En idé som liknar moderna online-IDE:er, men för den decentraliserade webben.

Arbeta med Hypercore-API:et: kodexempel

Beaker lade till ett beaker-namnområde på det globala window-objektet med flera viktiga API:er. Låt oss bryta ner de viktigaste; all kod har verifierats mot projektdokumentationen.

Arbeta med Hyperdrive-filsystemet

API:et beaker.hyperdrive gav direkt åtkomst till P2P-webbplatsfiler. Så här såg det ut att skapa en enhet, skriva och läsa:

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

Metoderna är intuitiva och liknar Node.js fs-modul: writeFile, readFile, stat, unlink, readdir. Skillnaden är att data inte skrivs till lokal disk utan till peer-to-peer-nätverket, och alla andra användare med åtkomst till denna enhet kan läsa den.

Fråga filsystemet

API:et beaker.hyperdrive.query gjorde det möjligt att söka efter filer efter mönster över flera webbplatser samtidigt. Detta öppnade dörren för decentraliserade flöden, sökmotorer och sociala nätverk utan en central 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 anrop, och du får en tidssorterad lista med inlägg från mikrobloggar från alla webbplatser i sites-arrayen. Inga API-nycklar, ingen OAuth, ingen serverinfrastruktur.

Peer-to-peer-meddelanden

API:et beaker.peersockets gav direkt kommunikation mellan webbplatsanvändare, liknande WebSocket men körande över Hypercore-nätverket:

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
}

Detta API möjliggjorde byggandet av decentraliserade chattar, kollaborativa redigeringsverktyg och realtidsapplikationer där meddelanden går direkt från användare till användare utan en mellanliggande server.

Varför projektet lades ner: tre lärdomar från Beaker Browser

Den 27 december 2022 arkiverades Beaker-repot officiellt med en notering från Paul Frazee: "Tiden är kommen." Han gick vidare till Bluesky, ett decentraliserat socialt nätverk där AT-protokollet löser liknande problem men på en annan nivå.

Det fanns flera skäl till nedläggningen. För det första rörde sig P2P-webben aldrig bortom experimentstadiet. Den genomsnittlige användaren är inte redo att köra en webbläsare som inte stöder tillägg, inte synkroniserar bokmärken och inte fungerar med välbekanta webbplatser utan förbehåll. För det andra visade sig kallstartsproblemet för ett peer-to-peer-nätverk vara tufft: om webbplatsens författare är offline och andra besökare inte seedar, är webbplatsen otillgänglig. För det tredje visade sig Chromium vara en för tung grund för en nischad webbläsare: att underhålla en fork med anpassade API:er krävde resurser som ett team på tre personer inte hade.

Men lärdomarna från Beaker är mer värdefulla än själva webbläsaren. Projektet visade att en webbläsare inte bara kan vara ett fönster in i webben utan en fullfjädrad utvecklingsmiljö. Att hyper:// som protokoll har rätt att existera. Och att decentraliserade API:er (beaker.hyperdrive, beaker.peersockets) kan vara lika bekväma som fetch eller localStorage.

Video: Beaker Browser i aktion

Se en demonstration av Beaker av Paul Frazee, en inspelning från 2017 där han visar hur man skapar en P2P-webbplats i realtid:

På 5 minuter förklarar videon tydligare än några ord hur omedelbar publicering fungerade och varför idén var kraftfull.

Vad som kom sedan: Agregore och andra P2P-webbläsare

Andan från Beaker dog inte. Idag fortsätter flera projekt idén om en webbläsare för den decentraliserade webben:

Agregore Browser är en minimalistisk webbläsare för den distribuerade webben, med stöd för IPFS, Hypercore och BitTorrent-protokollen direkt ur lådan. Till skillnad från Beaker drar Agregore inte med sig hela Chromium, utan är byggd på lättviktiga Electron med fokus på P2P-protokoll. Tillägg från webbutiker stöds, HTTP-sajter fungerar som vanligt. Projektet har över 900 stjärnor på GitHub och uppdateras aktivt.

Peersky Browser är en annan experimentell P2P-webbläsare med stöd för IPFS, Hypercore och Web3. Peersky lägger till en egen uppsättning P2P-applikationer (peersky://p2p/) och fokuserar på integration med on-chain-data. Projektet är yngre än Agregore men utvecklas i samma riktning: webbläsaren som en plattform för den decentraliserade webben.

Själva Hypercore-protokollet lever vidare oberoende av någon webbläsare: det driver Keet (P2P-videosamtal från protokollskaparna) och andra decentraliserade applikationer.

⁉️🤔 Vanliga frågor

Kan man ladda ner och köra Beaker Browser nu?

Binära byggen finns fortfarande tillgängliga på GitHub releases-sidan för Windows, macOS och Linux. Webbläsaren startar, men P2P-nätverket är i praktiken tomt: de flesta peers är offline, sajter är otillgängliga. För experiment med Hypercore-protokollet bör du titta på Agregore eller Keet istället.

Ja, installationsfilerna ligger kvar på GitHub Releases. Men det finns ingen praktisk poäng med att installera det idag: Beaker-nätverket är dött, dokumentationen på docs.beakerbrowser.com är otillgänglig och projektet har inte fått några säkerhetsuppdateringar sedan 2022. För att förstå konceptet räcker källkoden på GitHub och videodemonstrationer.

Hur skilde sig Beaker från en vanlig webbläsare med torrent-tillägg?

Beaker var en komplett plattform, inte ett tillägg. Ett torrent-tillägg laddar bara ner filer, medan Beaker gav sajter ett JavaScript-API för att läsa, skriva, söka i filsystemet och skicka direktmeddelanden mellan användare. Allt detta fungerade som en del av webbplattformen, inte som en extern plugin.

En vanlig webbläsare med en torrentklient låter dig ladda ner en fil via en magnetlänk. Beaker gick längre: en sajt på hyper:// kunde söka efter innehåll på andra sajter med beaker.hyperdrive.query(), och utbyta meddelanden med besökare med beaker.peersockets. Detta är en annan integrationsnivå: P2P var inte en webbläsarfunktion utan själva grunden för webbplattformen.

Fungerade Beaker med vanliga HTTP-sajter?

Ja, fullt ut. Beaker var byggd på Chromium och öppnade alla HTTP/HTTPS-sajter korrekt. Problemet var det omvända: vanliga webbläsare stödde inte hyper://-protokollet, så P2P-sajter var osynliga för 99,9% av internetanvändarna. Detta var en av anledningarna till att projektet inte tog fart.

Kompatibiliteten var enkelriktad. Du kunde använda Beaker som en vanlig webbläsare för hela webben, men P2P-sajten du skapade var bara synlig för andra Beaker-användare. Massadoption krävde antingen stöd för hyper:// i Chrome och Firefox, eller gateways som Hashbase som översatte P2P-sajter till HTTP. Ingetdera skedde i tillräcklig skala.

Vad hände med Paul Frazee och teamet på Blue Link Labs?

Paul Frazee blev CTO för Bluesky, ett decentraliserat socialt nätverk byggt på AT Protocol. I ett inlägg på Bluesky förklarar han att erfarenheterna från Beaker direkt påverkade AT Protocols arkitektur. Blue Link Labs upphörde att existera. Den andra nyckelpersonen i projektet, Tara Vancil, skrev ett rörande inlägg "A Fond Farewell to Beaker" om projektets upp- och nedgångar.

Tekniskt sett övergav Frazee inte decentralisering, utan bytte till en annan nivå. Istället för en webbläsare för P2P-webben bygger han ett protokoll för ett decentraliserat socialt nätverk. AT Protocol i Bluesky löser många problem som Beaker snubblade på: en federerad modell istället för rent peer-to-peer, tydlig separation mellan servrar och klienter, stöd för skalning.

Finns det någon poäng med att studera Beaker idag?

Som kodbas, ja. Källkoden på GitHub visar hur man integrerar ett P2P-protokoll i en Electron-applikation, hur man designar ett API för ett decentraliserat filsystem och hur man bygger webbläsartillägg med anpassade protokoll. Som produkt, nej, men som ett utbildningsprojekt kring decentraliserad teknik, absolut.

Beakers källkod representerar 6 752 stjärnor på GitHub och dussintals repositories med experiment kring Hypercore-protokollet. För en utvecklare intresserad av P2P-teknik är detta en guldgruva av arkitekturbeslut: från hantering av anpassade protokoll i Electron till att bygga append-only-loggar baserade på Hypercore.

Är det värt att blicka tillbaka på Beaker 2026

Beaker Browser blev aldrig mainstream. Men det visade att en alternativ webbmodell är möjlig: en modell där användaren inte är separerad från servern av en stack av CDN:er, lastbalanserare och API-gateways, utan själv är en nod i nätverket.

Beakers idéer migrerade till Bluesky, Hypercore-protokollet lever vidare i Keet och andra projekt, och Agregore Browser fortsätter experimentet med en P2P-webbläsare för flera protokoll än idag. Om du är webbutvecklare och vill förstå vart den decentraliserade webben är på väg, börja med Beakers källkod på GitHub och den aktiva Agregore.

Experimentet lyckades inte, men själva idén visade sig vara smittsam. Och det är kanske viktigare än marknadsframgång.