Czym jest Beaker Browser i dlaczego wciąż się o nim mówi

Internet, jaki znamy, opiera się na architekturze klient-serwer. Wpisują Państwo adres, przeglądarka łączy się z serwerem gdzieś w centrum danych AWS lub Cloudflare, pobiera HTML i renderuje stronę. Jeśli serwer padnie, strony nie ma. W 2016 roku niewielki zespół Blue Link Labs pod kierownictwem Paula Frazee zaproponował alternatywę: a co, gdyby każdy użytkownik sam stawał się serwerem?

Tak powstał Beaker Browser, eksperymentalna przeglądarka oparta na Electronie i Chromium, która wykorzystywała protokół Hypercore (początkowo Dat) do publikacji treści w sieci peer-to-peer. Żadnego backendu, żadnego hostingu: tworzą Państwo stronę bezpośrednio w przeglądarce, a inni użytkownicy łączą się z Państwa komputerem bezpośrednio.

Projekt zarchiwizowano w grudniu 2022 roku, ale jego idee nie zniknęły. Paul Frazee został CTO Bluesky, a sam protokół Hypercore nadal żyje i się rozwija. Dalej o tym, jak Beaker działał od środka, jakie P2P-API otrzymywali webdeveloperzy i czym go dziś zastąpić. Jeśli budują Państwo coś w zdecentralizowanym internecie, te lekcje zaoszczędzą Państwu tygodni prób i błędów.

💡 Szybki przegląd:

• Proszę zainstalować Beaker z wydań na GitHub dla Windows, macOS lub Linux. Pliki binarne są wciąż dostępne, osobny hosting nie jest potrzebny.

• Proszę kliknąć „Create New Site", przeglądarka wygeneruje stronę z adresem hyper:// bezpośrednio na Państwa komputerze. Żadnych DNS-ów, nginxa i wdrożeń.

• Proszę edytować pliki we wbudowanym edytorze kodu i Hyperdrive, przekazać adres hyper:// innemu użytkownikowi Beaker, a on połączy się z Państwem bezpośrednio.

• Projekt zamknięto w 2022 roku: sieć jest prawie pusta. Do eksperymentów roboczych z Hypercore proszę zwrócić uwagę na Agregore i Peersky Browser.

Jak Beaker Browser wymyślał internet na nowo

Beaker nie był jedynie nakładką na Chromium z obsługą torrentów. Była to pełnoprawna przeglądarka, która dodawała do platformy webowej nową warstwę: możliwość czytania i zapisywania plików bezpośrednio w sieci peer-to-peer.

Gdy wchodzili Państwo na stronę z protokołem hyper://, Beaker pobierał jej pliki z komputerów innych użytkowników, którzy tę stronę odwiedzali. A po pobraniu sami Państwo zaczynali udostępniać pobrane pliki, tymczasowo, dopóki strona jest otwarta, lub stale, jeśli włączono seedowanie. Przypominało to BitTorrenta, ale wbudowanego bezpośrednio w przeglądarkę i powiązanego z adresami webowymi.

Sześć możliwości, dla których warto było zainstalować Beaker

Natychmiastowa publikacja stron. Klikali Państwo „Create New Site", a Beaker generował stronę z adresem hyper://. Strona była od razu dostępna w sieci, każdy, kto miał Beaker, mógł ją otworzyć, znając adres. Żadnej konfiguracji DNS, nginxa i wdrożeń.

Współdzielony hosting. Im więcej odwiedzających wchodziło na stronę P2P, tym szybciej się ona ładowała, każdy odwiedzający pomagał w dystrybucji treści. Zmniejszało to obciążenie autora: nie był potrzebny mocny serwer na szczycie ruchu, sieć skalowała się sama.

Aplikacje P2P w technologiach webowych. Beaker udostępniał JavaScript-API beaker.hyperdrive do odczytu i zapisu w peer-to-peerowym systemie plików. Oznaczało to, że aplikacja webowa mogła przechowywać dane nie na serwerze, lecz w zdecentralizowanej sieci, a użytkownik sam kontrolował swoje pliki.

System plików Hyperdrive. Każda strona w Beaker była nie tylko zbiorem podstron, ale pełnoprawnym systemem plików z wersjonowaniem. Mogli Państwo przeglądać strukturę strony jak w menedżerze plików, widzieć historię zmian, a nawet forkować cudze projekty, podobnie jak na GitHubie, ale dla całego internetu.

Wbudowany terminal. W Beaker znajdował się Webterm, środowisko wiersza poleceń bezpośrednio w przeglądarce. Deweloperzy mogli uruchamiać skrypty, zarządzać plikami i wchodzić w interakcje z API, nie opuszczając okna przeglądarki.

Edytor kodu źródłowego. Zintegrowany edytor umożliwiał edycję HTML, CSS i JavaScriptu strony i natychmiastowe oglądanie rezultatu, side-by-side z otwartą stroną. Pomysł podobny do współczesnych online-IDE, ale dla zdecentralizowanego internetu.

Jak pracować z Hypercore API: przykłady kodu

Beaker dodawał do globalnego obiektu window przestrzeń nazw beaker z kilkoma kluczowymi API. Przeanalizujmy najważniejsze; cały kod został zweryfikowany zgodnie z dokumentacją projektu.

Praca z systemem plików Hyperdrive

API beaker.hyperdrive zapewniało bezpośredni dostęp do plików witryny P2P. Oto jak wyglądało tworzenie dysku, zapis i odczyt:

1
const drive = await beaker.hyperdrive.createDrive()
2
 
3
await drive.readdir('/')
4
await drive.writeFile('/hello.md', '# Привет, P2P-веб!')
5
 
6
const stat = await drive.stat('/hello.md')
7
console.log('Размер:', stat.size, 'байт')
8
console.log('Изменен:', stat.mtime)
9
 
10
const content = await drive.readFile('/hello.md', 'utf8')
11
console.log(content) // '# Привет, P2P-веб!'
12
 
13
await drive.unlink('/hello.md')

Metody są intuicyjne i przypominają moduł Node.js fs: writeFile, readFile, stat, unlink, readdir. Różnica polega na tym, że dane nie są zapisywane na dysku lokalnym, lecz w sieci peer-to-peer, a każdy inny użytkownik mający dostęp do tego dysku może je odczytać.

Zapytania do systemu plików

API beaker.hyperdrive.query umożliwiało wyszukiwanie plików według wzorca na wielu witrynach jednocześnie. Otwierało to drogę do zdecentralizowanych kanałów, wyszukiwarek i sieci społecznościowych bez centralnego serwera:

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
}

Jedno wywołanie i otrzymują Państwo posortowaną chronologicznie listę wpisów z mikroblogów wszystkich witryn w tablicy sites. Bez kluczy API, bez OAuth, bez infrastruktury serwerowej.

Komunikacja peer-to-peer

API beaker.peersockets zapewniało bezpośrednią łączność między użytkownikami witryny, odpowiednik WebSocket, ale działający w oparciu o sieć 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, 'говорит:', message)
6
})
7
 
8
function sendToPeer(peerId, message) {
9
  const encoded = new TextEncoder('utf-8').encode(message)
10
  topic.send(peerId, encoded)
11
}

To API umożliwiało budowanie zdecentralizowanych czatów, edytorów współpracujących i aplikacji czasu rzeczywistego, w których wiadomości przesyłane są bezpośrednio od użytkownika do użytkownika, bez serwera pośredniczącego.

Dlaczego projekt zamknięto: trzy lekcje Beaker Browser

27 grudnia 2022 roku repozytorium Beaker zostało oficjalnie zarchiwizowane z adnotacją od Paula Frazee: „Nadszedł czas". Przeszedł do Bluesky, zdecentralizowanej sieci społecznościowej, gdzie protokół AT Protocol rozwiązuje podobne zadania, ale na innym poziomie.

Przyczyn zamknięcia było kilka. Po pierwsze, P2P-web nigdy nie wyszedł poza fazę eksperymentu. Masowy użytkownik nie jest gotów uruchamiać przeglądarki, która nie obsługuje rozszerzeń, nie synchronizuje zakładek i nie działa ze zwykłymi witrynami bez zastrzeżeń. Po drugie, zimny start sieci peer-to-peer okazał się brutalny: jeśli autor witryny jest offline, a inni odwiedzający jej nie seedują, witryna jest niedostępna. Po trzecie, Chromium okazał się zbyt ciężką podstawą dla niszowej przeglądarki: utrzymanie forka z niestandardowymi API wymagało zasobów, których trzyosobowy zespół nie posiadał.

Jednak lekcje z Beaker są cenniejsze niż sama przeglądarka. Projekt pokazał, że przeglądarka może być nie tylko oknem na web, ale pełnoprawnym środowiskiem programistycznym. Że hyper:// jako protokół ma prawo bytu. I że zdecentralizowane API, beaker.hyperdrive, beaker.peersockets, mogą być równie wygodne jak fetch czy localStorage.

Wideo: Beaker Browser w działaniu

Proszę obejrzeć demonstrację Beaker autorstwa Paula Frazee, nagranie z 2017 roku, w którym pokazuje on tworzenie witryny P2P w czasie rzeczywistym:

W ciągu 5 minut wideo wyjaśnia lepiej niż jakiekolwiek słowa, jak działała natychmiastowa publikacja i dlaczego pomysł był tak mocny.

Co pojawiło się w zamian: Agregore i inne przeglądarki P2P

Duch Beaker nie umarł. Obecnie istnieje kilka projektów kontynuujących ideę przeglądarki dla zdecentralizowanego webu:

Agregore Browser, minimalistyczna przeglądarka dla rozproszonego internetu, obsługująca protokoły IPFS, Hypercore i BitTorrent od razu po instalacji. W przeciwieństwie do Beakera, Agregore nie ciągnie za sobą pełnego Chromium, lecz jest zbudowany na lekkim Electronie z naciskiem na protokoły P2P. Rozszerzenia ze sklepu internetowego są obsługiwane, strony HTTP działają normalnie. Na GitHubie projekt ma ponad 900 gwiazdek i jest aktywnie aktualizowany.

Peersky Browser, kolejna eksperymentalna przeglądarka P2P z obsługą IPFS, Hypercore i Web3. Peersky dodaje własny zestaw aplikacji P2P (peersky://p2p/) i koncentruje się na integracji z danymi on-chain. Projekt jest młodszy od Agregore, ale rozwija się w tym samym kierunku: przeglądarka jako platforma dla zdecentralizowanego internetu.

Sam protokół Hypercore nadal żyje niezależnie od przeglądarki: na jego bazie działają Keet (wideorozmowy P2P od twórców protokołu) oraz inne zdecentralizowane aplikacje.

⁉️🤔 Często zadawane pytania

Czy można teraz pobrać i uruchomić Beaker Browser?

Pliki binarne są nadal dostępne na stronie wydań GitHub dla Windows, macOS i Linux. Przeglądarka się uruchomi, ale sieć P2P jest praktycznie pusta: większość peerów jest odłączona, strony są niedostępne. Do eksperymentów z protokołem Hypercore lepiej spojrzeć w stronę Agregore lub Keet.

Tak, pliki instalacyjne wciąż znajdują się w GitHub Releases. Ale instalacja nie ma dziś praktycznego sensu: sieć Beaker jest martwa, dokumentacja na docs.beakerbrowser.com jest niedostępna, a sam projekt nie otrzymuje aktualizacji bezpieczeństwa od 2022 roku. Do zrozumienia koncepcji wystarczy kod źródłowy na GitHubie i demonstracje wideo.

Czym Beaker różnił się od zwykłej przeglądarki z rozszerzeniem torrentowym?

Beaker był kompletną platformą, a nie nakładką. Rozszerzenie torrentowe jedynie pobiera pliki, natomiast Beaker udostępniał stronom API JavaScript do odczytu, zapisu, wyszukiwania w systemie plików i bezpośredniej wymiany wiadomości między użytkownikami, a wszystko to działało jako część platformy webowej, a nie zewnętrzna wtyczka.

Zwykła przeglądarka z klientem torrent pozwala pobrać plik przez link magnet. Beaker szedł dalej: strona na hyper:// mogła przez beaker.hyperdrive.query() wyszukiwać treści na innych stronach, a przez beaker.peersockets wymieniać wiadomości z odwiedzającymi. To inny poziom integracji: P2P nie było funkcją przeglądarki, lecz fundamentem platformy webowej.

Czy Beaker działał ze zwykłymi stronami HTTP?

Tak, w pełni. Beaker był zbudowany na Chromium i poprawnie otwierał wszystkie strony HTTP/HTTPS. Problem leżał w drugą stronę: zwykłe przeglądarki nie obsługiwały protokołu hyper://, więc strony P2P były niewidoczne dla 99,9% użytkowników internetu. To stało się jedną z przyczyn, dla których projekt nie wypalił.

Kompatybilność była jednostronna. Można było używać Beakera jako zwykłej przeglądarki do całego internetu, ale stworzoną przez Pana/Panią stronę P2P widzieli tylko inni użytkownicy Beakera. Do masowego wdrożenia potrzebne było albo wsparcie hyper:// w Chrome i Firefox, albo bramki takie jak Hashbase, które tłumaczyły strony P2P na HTTP. Ani jedno, ani drugie nie zaistniało na wystarczającą skalę.

Co się stało z Paulem Frazee i zespołem Blue Link Labs?

Paul Frazee został CTO Bluesky, zdecentralizowanej sieci społecznościowej zbudowanej na protokole AT Protocol. W poście na Bluesky opowiada, że doświadczenia z Beakera bezpośrednio wpłynęły na architekturę AT Protocol. Blue Link Labs przestało istnieć. Druga kluczowa postać projektu, Tara Vancil, napisała wzruszający post „A Fond Farewell to Beaker" o wzlotach i upadkach projektu.

Technicznie rzecz biorąc, Frazee nie porzucił decentralizacji, tylko przeszedł na inny poziom. Zamiast przeglądarki dla internetu P2P buduje protokół dla zdecentralizowanej sieci społecznościowej. AT Protocol w Bluesky rozwiązuje wiele problemów, na których potknął się Beaker: model federacyjny zamiast czysto peer-to-peer, wyraźny podział na serwery i klientów, wsparcie skalowania.

Czy jest sens uczyć się Beakera dzisiaj?

Jako bazy kodu, tak. Kod źródłowy na GitHubie pokazuje, jak zintegrować protokół P2P z aplikacją Electron, jak projektować API dla zdecentralizowanego systemu plików i jak budować rozszerzenia przeglądarki z niestandardowymi protokołami. Jako produkt, nie, ale jako projekt edukacyjny z zakresu technologii zdecentralizowanych, zdecydowanie tak.

Kod źródłowy Beakera to 6752 gwiazdki na GitHubie i kilkadziesiąt repozytoriów z eksperymentami wokół protokołu Hypercore. Dla programisty zainteresowanego technologiami P2P jest to źródło decyzji architektonicznych: od obsługi niestandardowych protokołów w Electronie po budowę dzienników tylko do dopisywania na bazie Hypercore.

Czy warto spoglądać wstecz na Beakera w 2026 roku

Beaker Browser nie stał się mainstreamem. Ale pokazał, że alternatywny model internetu jest możliwy, model, w którym użytkownik nie jest oddzielony od serwera stosem CDN, load balancerów i bram API, lecz sam jest węzłem sieci.

Idee Beakera przeniknęły do Bluesky, protokół Hypercore żyje w Keet i innych projektach, a Agregore Browser kontynuuje eksperyment z wieloprotokołową przeglądarką P2P już dziś. Jeśli jest Pan/Pani webdeveloperem i chce zrozumieć, dokąd zmierza zdecentralizowany internet, proszę zacząć od kodu źródłowego Beakera na GitHubie i działającego Agregore.

Eksperyment się nie powiódł, ale sama idea okazała się zaraźliwa. A to jest chyba ważniejsze niż sukces rynkowy.