🔬 Що таке Beaker Browser: огляд P2P-браузера, його API і сучасних спадкоємців

Q: Чи можна завантажити та запустити Beaker Browser зараз?

Бінарні збірки ще доступні на сторінці релізів GitHub для Windows, macOS та Linux. Браузер запуститься, але P2P-мережа практично порожня: більшість пірів відключені, сайти недоступні. Для експериментів із протоколом Hypercore краще подивитися в бік Agregore або Keet. Так, інсталяційні файли досі лежать на GitHub Releases. Але практичного сенсу в установці сьогодні немає: мережа Beaker мертва, документація на docs.beakerbrowser.com недоступна, а сам проєкт не отримує оновлень безпеки з 2022 року. Для розуміння концепції достатньо вихідного коду на GitHub та відеодемонстрацій.

Q: Чим Beaker відрізнявся від звичайного браузера з торент-розширенням?

Beaker був цілісною платформою, а не надбудовою. Торент-розширення лише завантажує файли, а Beaker надавав сайтам JavaScript API для читання, запису, пошуку у файловій системі та прямого обміну повідомленнями між користувачами, усе це працювало як частина веб-платформи, а не зовнішній плагін. Звичайний браузер із торент-клієнтом дозволяє вам завантажити файл за magnet-посиланням. Beaker ішов далі: сайт на hyper:// міг через beaker.hyperdrive.query() шукати контент на інших сайтах, а через beaker.peersockets, обмінюватися повідомленнями з відвідувачами. Це інший рівень інтеграції: P2P був не функцією браузера, а фундаментом веб-платформи.

Q: Чи працював Beaker зі звичайними HTTP-сайтами?

Так, повністю. Beaker був побудований на Chromium і коректно відкривав будь-які HTTP/HTTPS-сайти. Проблема була у зворотному: звичайні браузери не підтримували протокол hyper://, тому P2P-сайти були невидимими для 99,9% користувачів інтернету. Це й стало однією з причин, чому проєкт не злетів. Сумісність була односторонньою. Ви могли користуватися Beaker як звичайним браузером для всього вебу, але створений вами P2P-сайт бачили лише інші користувачі Beaker. Для масового впровадження була потрібна або підтримка hyper:// у Chrome та Firefox, або шлюзи на кшталт Hashbase, які транслювали P2P-сайти в HTTP. Ні того, ні іншого в достатньому масштабі не сталося.

Q: Що сталося з Полом Фрейзі та командою Blue Link Labs?

Paul Frazee став CTO Bluesky, децентралізованої соціальної мережі, побудованої на протоколі AT Protocol. У дописі на Bluesky він розповідає, що досвід Beaker безпосередньо вплинув на архітектуру AT Protocol. Blue Link Labs припинила існування. Друга ключова фігура проєкту, Tara Vancil, написала зворушливий допис «A Fond Farewell to Beaker» про злети та падіння проєкту. Технічно Фрейзі не закинув децентралізацію, а перейшов на інший рівень. Замість браузера для P2P-вебу він будує протокол для децентралізованої соціальної мережі. AT Protocol у Bluesky вирішує багато проблем, на яких спіткнувся Beaker: федеративна модель замість суто пірингової, чітке розділення на сервери та клієнти, підтримка масштабування.

Q: Чи є сенс вивчати Beaker сьогодні?

Як кодову базу, так. Вихідний код на GitHub показує, як інтегрувати P2P-протокол у Electron-застосунок, як проєктувати API для децентралізованої файлової системи та як будувати браузерні розширення з кастомними протоколами. Як продукт, ні, але як навчальний проєкт із децентралізованих технологій, безумовно. Вихідний код Beaker — це 6 752 зірки на GitHub і кілька десятків репозиторіїв з експериментами навколо протоколу Hypercore. Для розробника, який цікавиться P2P-технологіями — це джерело архітектурних рішень: від обробки кастомних протоколів в Electron до побудови журналів лише для додавання на базі Hypercore.

Що таке Beaker Browser і чому про нього досі говорять

Інтернет, яким ми його знаємо, побудований на клієнт-серверній архітектурі. Ви вводите адресу, браузер звертається до сервера десь у дата-центрі AWS або Cloudflare, забирає HTML і рендерить сторінку. Якщо сервер впав, сайту немає. У 2016 році невелика команда Blue Link Labs під керівництвом Paul Frazee запропонувала альтернативу: а що, як кожен користувач сам стає сервером?

Так з’явився Beaker Browser, експериментальний браузер на базі Electron і Chromium, який використовував протокол Hypercore (спочатку Dat) для peer-to-peer-публікації контенту. Жодного бекенду, жодного хостингу: ви створюєте сайт прямо в браузері, й інші користувачі підключаються до вашого комп’ютера напряму.

Проєкт заархівували в грудні 2022 року, але його ідеї нікуди не поділися. Paul Frazee став CTO Bluesky, а сам протокол Hypercore продовжує жити й розвиватися. Далі про те, як Beaker працював зсередини, які P2P-API отримували веброзробники та чим замінити його сьогодні. Якщо ви будуєте щось на децентралізованому вебі, ці уроки зекономлять вам тижні спроб і помилок.

Програмний код на екрані, децентралізована веб-розробка та пірингові протоколи

💡 Швидкий огляд:

Встановіть Beaker із релізів на GitHub для Windows, macOS або Linux. Бінарні збірки ще доступні, окремий хостинг не потрібен.
Натисніть «Create New Site», браузер згенерує сайт з адресою hyper:// прямо на вашому комп’ютері. Жодних DNS, nginx і деплою.
Редагуйте файли у вбудованому редакторі коду та Hyperdrive, передайте адресу hyper:// іншому користувачеві Beaker, він підключиться до вас напряму.
Проєкт закрито у 2022 році: мережа майже порожня. Для робочих експериментів із Hypercore зверніть увагу на Agregore та Peersky Browser.

Як Beaker Browser перевинаходив веб

Beaker не був просто оболонкою Chromium із підтримкою торентів. Це був повноцінний браузер, який додавав у вебплатформу новий шар: можливість читати й писати файли напряму в пірингову мережу.

Коли ви заходили на сайт із протоколом hyper://, Beaker завантажував його файли з комп’ютерів інших користувачів, які цей сайт відвідували. А після завантаження ви самі починали роздавати завантажені файли, тимчасово, поки сторінка відкрита, або постійно, якщо вмикали сідування. Це нагадувало BitTorrent, але вбудований прямо в браузер і прив’язаний до вебадрес.

Шість можливостей, заради яких варто було встановити Beaker

Миттєва публікація сайтів. Ви натискали «Create New Site», і Beaker генерував сайт з адресою hyper://. Сайт одразу був доступний у мережі, будь-хто, в кого стояв Beaker, міг відкрити його, знаючи адресу. Жодного налаштування DNS, nginx і деплою.

Спільний хостинг. Що більше відвідувачів заходило на P2P-сайт, то швидше він завантажувався, кожен відвідувач допомагав роздавати контент. Це знижувало навантаження на автора: не потрібен був потужний сервер на піку трафіку, мережа масштабувалася сама.

P2P-застосунки на вебтехнологіях. Beaker надавав JavaScript-API beaker.hyperdrive для читання й запису в пірингову файлову систему. Це означало, що вебзастосунок міг зберігати дані не на сервері, а в децентралізованій мережі, і користувач сам контролював свої файли.

Файлова система Hyperdrive. Кожен сайт у Beaker був не просто набором сторінок, а повноцінною файловою системою з версіонуванням. Ви могли переглядати структуру сайту як у файловому менеджері, бачити історію змін і навіть форкати чужі проєкти, схоже на GitHub, але для всього вебу.

Вбудований термінал. У Beaker був Webterm, середовище командного рядка прямо в браузері. Розробники могли запускати скрипти, керувати файлами та взаємодіяти з API, не покидаючи вікна браузера.

Редактор вихідного коду. Інтегрований редактор давав змогу правити HTML, CSS і JavaScript сайту й одразу бачити результат, side-by-side із відкритою сторінкою. Ідея, схожа на сучасні online-IDE, але для децентралізованого вебу.

Як працювати з Hypercore API: приклади коду

Beaker додавав у глобальний об’єкт window простір імен beaker із кількома ключовими API. Розберемо основні, весь код перевірено за документацією проєкту.

Робота з файловою системою Hyperdrive

API beaker.hyperdrive надавав прямий доступ до файлів P2P-сайту. Ось як виглядало створення диска, запис і читання:

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

Методи інтуїтивні та схожі на модуль Node.js fs: writeFile, readFile, stat, unlink, readdir. Різниця в тому, що дані пишуться не на локальний диск, а в пірингову мережу, і будь-який інший користувач із доступом до цього диска може їх прочитати.

Запити до файлової системи

API beaker.hyperdrive.query дозволяв шукати файли за маскою на багатьох сайтах одночасно. Це відкривало шлях до децентралізованих стрічок, пошукових рушіїв і соціальних мереж без центрального сервера:

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 }

Один виклик, і ви отримуєте відсортований за часом список дописів із мікроблогів усіх сайтів у масиві sites. Без API-ключів, без OAuth, без серверної інфраструктури.

Peer-to-peer повідомлення

API beaker.peersockets забезпечував прямий зв’язок між користувачами сайту, аналог WebSocket, але який працює поверх мережі 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 }

Цей API дозволяв будувати децентралізовані чати, колаборативні редактори та real-time-застосунки, де повідомлення йдуть напряму від користувача до користувача, без проміжного сервера.

Чому проєкт закрили: три уроки Beaker Browser

27 грудня 2022 року репозиторій Beaker було офіційно заархівовано з позначкою від Paul Frazee: «Час настав». Він перейшов у Bluesky, децентралізовану соціальну мережу, де протокол AT Protocol вирішує схожі завдання, але на іншому рівні.

Причин закриття було кілька. По-перше, P2P-веб так і не вийшов за межі експерименту. Масовий користувач не готовий запускати браузер, який не підтримує розширення, не синхронізує закладки та не працює зі звичними сайтами без застережень. По-друге, холодний старт пірингової мережі виявився жорстоким: якщо автор сайту не в мережі, а інші відвідувачі не сідують, сайт недоступний. По-третє, Chromium виявився надто важкою основою для нішевого браузера: підтримка форку з кастомними API потребувала ресурсів, яких у команди з трьох осіб не було.

Але уроки Beaker цінніші за сам браузер. Проєкт показав, що браузер може бути не просто вікном у веб, а повноцінним середовищем розробки. Що hyper:// як протокол має право на життя. І що децентралізовані API, beaker.hyperdrive, beaker.peersockets, можуть бути такими ж зручними, як fetch чи localStorage.

Відео: Beaker Browser у дії

Подивіться демонстрацію Beaker від Paul Frazee, запис 2017 року, де він показує створення P2P-сайту в реальному часі:

За 5 хвилин відео зрозуміліше за будь-які слова пояснює, як працювала миттєва публікація і чому ідея була сильною.

Що прийшло на зміну: Agregore та інші P2P-браузери

Дух Beaker не помер. Сьогодні існує кілька проєктів, які продовжують ідею браузера для децентралізованого вебу:

Інтерфейс Agregore Browser, браузер для розподіленого вебу з підтримкою IPFS та Hypercore

Agregore Browser, мінімалістичний браузер для розподіленого вебу, що підтримує протоколи IPFS, Hypercore та BitTorrent просто з коробки. На відміну від Beaker, Agregore не тягне за собою повний Chromium, а побудований на легковажному Electron із фокусом на P2P-протоколи. Розширення з веб-магазину підтримуються, HTTP-сайти працюють як зазвичай. На GitHub у проєкту понад 900 зірок, і він активно оновлюється.

Peersky Browser, ще один експериментальний P2P-браузер із підтримкою IPFS, Hypercore та Web3. Peersky додає власний набір P2P-застосунків (peersky://p2p/) і фокусується на інтеграції з ончейн-даними. Проєкт молодший за Agregore, але розвивається в тому ж напрямку: браузер як платформа для децентралізованого вебу.

Сам протокол Hypercore продовжує жити окремо від браузера: на його основі працюють Keet (P2P-відеодзвінки від творців протоколу) та інші децентралізовані застосунки.

⁉️🤔 Часті запитання

Чи можна завантажити та запустити Beaker Browser зараз?

Бінарні збірки ще доступні на сторінці релізів GitHub для Windows, macOS та Linux. Браузер запуститься, але P2P-мережа практично порожня: більшість пірів відключені, сайти недоступні. Для експериментів із протоколом Hypercore краще подивитися в бік Agregore або Keet.

Так, інсталяційні файли досі лежать на GitHub Releases. Але практичного сенсу в установці сьогодні немає: мережа Beaker мертва, документація на docs.beakerbrowser.com недоступна, а сам проєкт не отримує оновлень безпеки з 2022 року. Для розуміння концепції достатньо вихідного коду на GitHub та відеодемонстрацій.

Чим Beaker відрізнявся від звичайного браузера з торент-розширенням?

Beaker був цілісною платформою, а не надбудовою. Торент-розширення лише завантажує файли, а Beaker надавав сайтам JavaScript API для читання, запису, пошуку у файловій системі та прямого обміну повідомленнями між користувачами, усе це працювало як частина веб-платформи, а не зовнішній плагін.

Звичайний браузер із торент-клієнтом дозволяє вам завантажити файл за magnet-посиланням. Beaker ішов далі: сайт на hyper:// міг через beaker.hyperdrive.query() шукати контент на інших сайтах, а через beaker.peersockets, обмінюватися повідомленнями з відвідувачами. Це інший рівень інтеграції: P2P був не функцією браузера, а фундаментом веб-платформи.

Чи працював Beaker зі звичайними HTTP-сайтами?

Так, повністю. Beaker був побудований на Chromium і коректно відкривав будь-які HTTP/HTTPS-сайти. Проблема була у зворотному: звичайні браузери не підтримували протокол hyper://, тому P2P-сайти були невидимими для 99,9% користувачів інтернету. Це й стало однією з причин, чому проєкт не злетів.

Сумісність була односторонньою. Ви могли користуватися Beaker як звичайним браузером для всього вебу, але створений вами P2P-сайт бачили лише інші користувачі Beaker. Для масового впровадження була потрібна або підтримка hyper:// у Chrome та Firefox, або шлюзи на кшталт Hashbase, які транслювали P2P-сайти в HTTP. Ні того, ні іншого в достатньому масштабі не сталося.

Що сталося з Полом Фрейзі та командою Blue Link Labs?

Paul Frazee став CTO Bluesky, децентралізованої соціальної мережі, побудованої на протоколі AT Protocol. У дописі на Bluesky він розповідає, що досвід Beaker безпосередньо вплинув на архітектуру AT Protocol. Blue Link Labs припинила існування. Друга ключова фігура проєкту, Tara Vancil, написала зворушливий допис «A Fond Farewell to Beaker» про злети та падіння проєкту.

Технічно Фрейзі не закинув децентралізацію, а перейшов на інший рівень. Замість браузера для P2P-вебу він будує протокол для децентралізованої соціальної мережі. AT Protocol у Bluesky вирішує багато проблем, на яких спіткнувся Beaker: федеративна модель замість суто пірингової, чітке розділення на сервери та клієнти, підтримка масштабування.

Чи є сенс вивчати Beaker сьогодні?

Як кодову базу, так. Вихідний код на GitHub показує, як інтегрувати P2P-протокол у Electron-застосунок, як проєктувати API для децентралізованої файлової системи та як будувати браузерні розширення з кастомними протоколами. Як продукт, ні, але як навчальний проєкт із децентралізованих технологій, безумовно.

Вихідний код Beaker — це 6 752 зірки на GitHub і кілька десятків репозиторіїв з експериментами навколо протоколу Hypercore. Для розробника, який цікавиться P2P-технологіями — це джерело архітектурних рішень: від обробки кастомних протоколів в Electron до побудови журналів лише для додавання на базі Hypercore.

Чи варто озиратися на Beaker у 2026 році

Beaker Browser не став мейнстримом. Але він показав, що альтернативна модель вебу можлива, модель, де користувач не відділений від сервера стеком із CDN, балансувальників та API-шлюзів, а сам є вузлом мережі.

Ідеї Beaker перекочували в Bluesky, протокол Hypercore живе в Keet та інших проєктах, а Agregore Browser продовжує експеримент із мультипротокольним P2P-браузером уже сьогодні. Якщо ви веброзробник і хочете зрозуміти, куди рухається децентралізований веб, почніть із вихідного коду Beaker на GitHub і живого Agregore.

Експеримент не вдався, але сама ідея виявилася заразливою. А це, мабуть, важливіше за ринковий успіх.