Что такое 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 и BitTorrent прямо из коробки. В отличие от Beaker, Agregore не тянет за собой полный Chromium, а построен на легковесном Electron с фокусом на P2P-протоколы. Расширения веб-магазина поддерживаются, HTTP-сайты работают как обычно. На GitHub у проекта более 900 звезд, и он активно обновляется.

Peersky Browser, еще один экспериментальный P2P-браузер с поддержкой IPFS, Hypercore и Web3. Peersky добавляет собственный набор P2P-приложений (peersky://p2p/) и фокусируется на интеграции с on-chain данными. Проект моложе 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. Для массового adoption требовалась либо поддержка 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 до построения append-only журналов на базе Hypercore.

Стоит ли оглядываться на Beaker в 2026 году

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

Идеи Beaker перекочевали в Bluesky, Hypercore-протокол живет в Keet и других проектах, а Agregore Browser продолжает эксперимент с мультипротокольным P2P-браузером уже сегодня. Если вы веб-разработчик и хотите понять, куда движется децентрализованный веб, начните с исходников Beaker на GitHub и живого Agregore.

Эксперимент не удался, но сама идея оказалась заразительной. А это, пожалуй, важнее рыночного успеха.