Was ist Beaker Browser und warum spricht man immer noch darüber

Das Internet, wie wir es kennen, basiert auf einer Client-Server-Architektur. Sie geben eine Adresse ein, der Browser geht zu einem Server irgendwo in einem AWS- oder Cloudflare-Rechenzentrum, holt das HTML und stellt die Seite dar. Fällt der Server aus, ist die Seite weg. 2016 schlug ein kleines Team bei Blue Link Labs unter der Leitung von Paul Frazee eine Alternative vor: Was wäre, wenn jeder Nutzer sein eigener Server würde?

So entstand Beaker Browser, ein experimenteller Browser auf Basis von Electron und Chromium, der das Hypercore-Protokoll (ursprünglich Dat) für die Peer-to-Peer-Veröffentlichung von Inhalten nutzte. Kein Backend, kein Hosting: Sie erstellen eine Seite direkt im Browser, und andere Nutzer verbinden sich direkt mit Ihrem Computer.

Das Projekt wurde im Dezember 2022 archiviert, aber seine Ideen leben weiter. Paul Frazee wurde CTO von Bluesky, und das Hypercore-Protokoll selbst entwickelt sich weiter. Im Folgenden erfahren Sie, wie Beaker unter der Haube funktionierte, auf welche P2P-APIs Webentwickler Zugriff hatten und was es heute ersetzen kann. Wenn Sie etwas im dezentralen Web aufbauen, werden Ihnen diese Erkenntnisse wochenlanges Ausprobieren ersparen.

💡 Kurzer Überblick:

• Installieren Sie Beaker von den GitHub-Releases für Windows, macOS oder Linux. Binär-Builds sind weiterhin verfügbar, kein separates Hosting erforderlich.

• Klicken Sie auf „Create New Site", und der Browser generiert eine Seite mit einer hyper://-Adresse direkt auf Ihrem Computer. Kein DNS, kein nginx, kein Deployment.

• Bearbeiten Sie Dateien im integrierten Code-Editor und Hyperdrive, teilen Sie die hyper://-Adresse mit einem anderen Beaker-Nutzer, und dieser verbindet sich direkt mit Ihnen.

• Das Projekt wurde 2022 eingestellt: Das Netzwerk ist nahezu leer. Für funktionierende Experimente mit Hypercore sehen Sie sich Agregore und Peersky Browser an.

Wie Beaker Browser das Web neu erfand

Beaker war nicht nur ein Chromium-Wrapper mit Torrent-Unterstützung. Es war ein vollwertiger Browser, der der Webplattform eine neue Ebene hinzufügte: die Fähigkeit, Dateien direkt in einem Peer-to-Peer-Netzwerk zu lesen und zu schreiben.

Wenn Sie eine Seite mit dem hyper://-Protokoll besuchten, lud Beaker deren Dateien von den Computern anderer Nutzer, die diese Seite besucht hatten. Nach dem Herunterladen begannen Sie selbst, die Dateien zu verteilen, entweder temporär, solange die Seite geöffnet war, oder dauerhaft, wenn Sie das Seeding aktivierten. Es ähnelte BitTorrent, war aber direkt in den Browser integriert und an Webadressen gebunden.

Sechs Funktionen, die Beaker einen Versuch wert machten

Sofortige Veröffentlichung von Seiten. Sie klickten auf „Create New Site", und Beaker generierte eine Seite mit einer hyper://-Adresse. Die Seite war sofort im Netzwerk verfügbar; jeder mit Beaker konnte sie öffnen, wenn er die Adresse kannte. Keine DNS-Konfiguration, kein nginx, kein Deployment.

Kollaboratives Hosting. Je mehr Besucher eine P2P-Seite aufriefen, desto schneller lud sie, denn jeder Besucher half mit, die Inhalte zu verteilen. Das reduzierte die Last für den Autor: Bei Traffic-Spitzen war kein leistungsfähiger Server nötig, das Netzwerk skalierte sich selbst.

P2P-Anwendungen mit Webtechnologien. Beaker stellte die beaker.hyperdrive-JavaScript-API zum Lesen und Schreiben in einem Peer-to-Peer-Dateisystem bereit. Das bedeutete, dass eine Webanwendung Daten nicht auf einem Server, sondern in einem dezentralen Netzwerk speichern konnte und die Nutzer ihre eigenen Dateien kontrollierten.

Das Hyperdrive-Dateisystem. Jede Seite in Beaker war nicht nur eine Ansammlung von Seiten, sondern ein vollwertiges Dateisystem mit Versionierung. Sie konnten die Seitenstruktur wie in einem Dateimanager durchsuchen, den Änderungsverlauf einsehen und sogar Projekte anderer forken, ähnlich wie bei GitHub, aber für das gesamte Web.

Integriertes Terminal. Beaker enthielt Webterm, eine Kommandozeilen-Umgebung direkt im Browser. Entwickler konnten Skripte ausführen, Dateien verwalten und mit APIs interagieren, ohne das Browserfenster zu verlassen.

Quellcode-Editor. Der integrierte Editor erlaubte es, HTML, CSS und JavaScript der Seite zu bearbeiten und das Ergebnis sofort, Seite an Seite mit der geöffneten Seite, zu sehen. Eine Idee, die modernen Online-IDEs ähnelt, aber für das dezentrale Web.

Arbeiten mit der Hypercore-API: Codebeispiele

Beaker fügte dem globalen window-Objekt einen beaker-Namespace mit mehreren zentralen APIs hinzu. Sehen wir uns die wichtigsten im Detail an; sämtlicher Code wurde anhand der Projektdokumentation überprüft.

Arbeiten mit dem Hyperdrive-Dateisystem

Die beaker.hyperdrive-API bot direkten Zugriff auf die Dateien von P2P-Websites. So sahen das Anlegen eines Laufwerks, das Schreiben und das Lesen aus:

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

Die Methoden sind intuitiv und ähneln dem Node.js-Modul fs: writeFile, readFile, stat, unlink, readdir. Der Unterschied besteht darin, dass die Daten nicht auf eine lokale Festplatte geschrieben werden, sondern in das Peer-to-Peer-Netzwerk, und jeder andere Nutzer mit Zugriff auf dieses Laufwerk kann sie lesen.

Abfragen des Dateisystems

Die beaker.hyperdrive.query-API ermöglichte die Suche nach Dateien anhand eines Musters über mehrere Websites hinweg und das gleichzeitig. Dies öffnete die Tür zu dezentralen Feeds, Suchmaschinen und sozialen Netzwerken ohne zentralen 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
}

Ein einziger Aufruf, und Sie erhalten eine zeitlich sortierte Liste von Beiträgen aus den Microblogs aller Websites im sites-Array. Keine API-Schlüssel, kein OAuth, keine Server-Infrastruktur.

Peer-to-Peer-Nachrichten

Die beaker.peersockets-API stellte eine direkte Kommunikation zwischen Website-Nutzern bereit, ähnlich wie WebSocket, jedoch über das Hypercore-Netzwerk:

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
}

Diese API ermöglichte den Bau dezentraler Chats, kollaborativer Editoren und Echtzeitanwendungen, bei denen Nachrichten direkt von Nutzer zu Nutzer gehen, ohne einen zwischengeschalteten Server.

Warum das Projekt eingestellt wurde: drei Lehren aus dem Beaker Browser

Am 27. Dezember 2022 wurde das Beaker-Repository offiziell mit einer Notiz von Paul Frazee archiviert: „The time has come." Er wechselte zu Bluesky, einem dezentralen sozialen Netzwerk, in dem das AT Protocol ähnliche Probleme löst, jedoch auf einer anderen Ebene.

Es gab mehrere Gründe für die Einstellung. Erstens kam das P2P-Web nie über das Experimentierstadium hinaus. Der durchschnittliche Nutzer ist nicht bereit, einen Browser zu verwenden, der keine Erweiterungen unterstützt, keine Lesezeichen synchronisiert und nicht ohne Einschränkungen mit vertrauten Websites funktioniert. Zweitens erwies sich das Kaltstartproblem für ein Peer-to-Peer-Netzwerk als gravierend: Ist der Website-Autor offline und verteilen andere Besucher die Daten nicht mit, ist die Website nicht verfügbar. Drittens stellte sich Chromium als zu schweres Fundament für einen Nischenbrowser heraus: Die Pflege eines Forks mit eigenen APIs erforderte Ressourcen, die ein Team von drei Personen nicht hatte.

Doch die Lehren aus Beaker sind wertvoller als der Browser selbst. Das Projekt zeigte, dass ein Browser nicht nur ein Fenster ins Web sein kann, sondern eine vollwertige Entwicklungsumgebung. Dass hyper:// als Protokoll eine Daseinsberechtigung hat. Und dass dezentrale APIs (beaker.hyperdrive, beaker.peersockets) so komfortabel sein können wie fetch oder localStorage.

Video: Beaker Browser in Aktion

Sehen Sie sich eine Demonstration von Beaker durch Paul Frazee an, eine Aufnahme von 2017, in der er zeigt, wie man in Echtzeit eine P2P-Website erstellt:

In 5 Minuten erklärt das Video klarer als alle Worte, wie das sofortige Publizieren funktionierte und warum die Idee so kraftvoll war.

Was danach kam: Agregore und andere P2P-Browser

Der Geist von Beaker ist nicht gestorben. Heute führen mehrere Projekte die Idee eines Browsers für das dezentrale Web fort:

Der Agregore Browser ist ein minimalistischer Browser für das verteilte Web, der die Protokolle IPFS, Hypercore und BitTorrent von Haus aus unterstützt. Anders als Beaker schleppt Agregore nicht das vollständige Chromium mit, sondern setzt auf schlankes Electron mit Fokus auf P2P-Protokolle. Erweiterungen aus dem Web Store werden unterstützt, HTTP-Seiten funktionieren wie gewohnt. Das Projekt hat über 900 Sterne auf GitHub und wird aktiv aktualisiert.

Der Peersky Browser ist ein weiterer experimenteller P2P-Browser mit Unterstützung für IPFS, Hypercore und Web3. Peersky bringt eigene P2P-Anwendungen mit (peersky://p2p/) und legt den Schwerpunkt auf die Integration mit On-Chain-Daten. Das Projekt ist jünger als Agregore, entwickelt sich aber in dieselbe Richtung: der Browser als Plattform für das dezentrale Web.

Das Hypercore-Protokoll selbst lebt unabhängig von jedem Browser weiter: Es treibt Keet an (P2P-Videoanrufe von den Protokollentwicklern) sowie andere dezentrale Anwendungen.

⁉️🤔 Häufig gestellte Fragen

Kann man den Beaker Browser jetzt noch herunterladen und ausführen?

Binäre Builds sind weiterhin verfügbar auf der GitHub-Releases-Seite für Windows, macOS und Linux. Der Browser startet, aber das P2P-Netzwerk ist praktisch leer: Die meisten Peers sind offline, Seiten sind nicht erreichbar. Für Experimente mit dem Hypercore-Protokoll sollten Sie stattdessen auf Agregore oder Keet schauen.

Ja, die Installationsdateien liegen noch auf GitHub Releases. Aber es hat heute keinen praktischen Nutzen, sie zu installieren: Das Beaker-Netzwerk ist tot, die Dokumentation unter docs.beakerbrowser.com ist nicht verfügbar, und das Projekt hat seit 2022 keine Sicherheitsupdates mehr erhalten. Um das Konzept zu verstehen, genügen der Quellcode auf GitHub und Videodemonstrationen.

Wie unterschied sich Beaker von einem normalen Browser mit Torrent-Erweiterung?

Beaker war eine vollständige Plattform, kein Add-on. Eine Torrent-Erweiterung lädt nur Dateien herunter, während Beaker Seiten eine JavaScript-API zum Lesen, Schreiben, Durchsuchen des Dateisystems und für direkte Nachrichten zwischen Nutzern bot. All das funktionierte als Teil der Webplattform, nicht als externes Plugin.

Ein normaler Browser mit Torrent-Client erlaubt Ihnen, eine Datei per Magnet-Link herunterzuladen. Beaker ging weiter: Eine Seite auf hyper:// konnte mit beaker.hyperdrive.query() Inhalte auf anderen Seiten suchen und mit beaker.peersockets Nachrichten mit Besuchern austauschen. Das ist eine andere Integrationsebene: P2P war kein Browser-Feature, sondern das Fundament der Webplattform.

Funktionierte Beaker mit normalen HTTP-Seiten?

Ja, vollständig. Beaker basierte auf Chromium und öffnete alle HTTP/HTTPS-Seiten korrekt. Das Problem war umgekehrt: Normale Browser unterstützten das hyper://-Protokoll nicht, sodass P2P-Seiten für 99,9% der Internetnutzer unsichtbar waren. Das war einer der Gründe, warum das Projekt nicht durchstartete.

Die Kompatibilität war einseitig. Sie konnten Beaker als normalen Browser für das gesamte Web nutzen, aber die von Ihnen erstellte P2P-Seite war nur für andere Beaker-Nutzer sichtbar. Für eine breite Akzeptanz hätte es entweder Unterstützung für hyper:// in Chrome und Firefox gebraucht oder Gateways wie Hashbase, die P2P-Seiten in HTTP übersetzten. Beides geschah nicht in ausreichendem Umfang.

Was wurde aus Paul Frazee und dem Team von Blue Link Labs?

Paul Frazee wurde CTO von Bluesky, einem dezentralen sozialen Netzwerk, das auf dem AT-Protokoll aufbaut. In einem Post auf Bluesky erklärt er, dass die Erfahrungen mit Beaker die Architektur des AT-Protokolls direkt beeinflusst haben. Blue Link Labs existiert nicht mehr. Die zweite Schlüsselfigur des Projekts, Tara Vancil, schrieb einen bewegenden Beitrag "A Fond Farewell to Beaker" über die Höhen und Tiefen des Projekts.

Technisch gesehen hat Frazee die Dezentralisierung nicht aufgegeben, sondern ist auf eine andere Ebene gewechselt. Statt eines Browsers für das P2P-Web baut er ein Protokoll für ein dezentrales soziales Netzwerk. Das AT-Protokoll in Bluesky löst viele Probleme, über die Beaker gestolpert ist: ein föderiertes Modell statt reinem Peer-to-Peer, klare Trennung zwischen Servern und Clients, Unterstützung für Skalierung.

Hat es heute noch Sinn, sich mit Beaker zu beschäftigen?

Als Codebasis, ja. Der Quellcode auf GitHub zeigt, wie man ein P2P-Protokoll in eine Electron-Anwendung integriert, wie man eine API für ein dezentrales Dateisystem gestaltet und wie man Browser-Erweiterungen mit benutzerdefinierten Protokollen baut. Als Produkt nein, aber als Lehrprojekt zu dezentralen Technologien absolut.

Der Beaker-Quellcode steht für 6.752 Sterne auf GitHub und Dutzende Repositories mit Experimenten rund um das Hypercore-Protokoll. Für einen Entwickler, der sich für P2P-Technologien interessiert, ist das eine Fundgrube architektonischer Entscheidungen: vom Umgang mit benutzerdefinierten Protokollen in Electron bis zum Aufbau von Append-only-Logs auf Basis von Hypercore.

Lohnt sich der Blick zurück auf Beaker im Jahr 2026

Beaker Browser ist nicht zum Mainstream geworden. Aber er hat gezeigt, dass ein alternatives Webmodell möglich ist: ein Modell, in dem der Nutzer nicht durch einen Stapel aus CDNs, Load Balancern und API-Gateways vom Server getrennt ist, sondern selbst ein Knoten im Netzwerk ist.

Beakers Ideen wanderten zu Bluesky, das Hypercore-Protokoll lebt in Keet und anderen Projekten weiter, und der Agregore Browser setzt das Experiment mit einem Multi-Protokoll-P2P-Browser bis heute fort. Wenn Sie als Webentwickler verstehen möchten, wohin sich das dezentrale Web entwickelt, beginnen Sie mit dem Beaker-Quellcode auf GitHub und dem aktiven Agregore.

Das Experiment war nicht erfolgreich, aber die Idee selbst erwies sich als ansteckend. Und das ist vielleicht wichtiger als Markterfolg.