Qué es Beaker Browser y por qué la gente sigue hablando de ello

Internet, tal como la conocemos, se basa en una arquitectura cliente-servidor. Usted escribe una dirección, el navegador acude a un servidor en algún centro de datos de AWS o Cloudflare, obtiene el HTML y muestra la página. Si el servidor se cae, el sitio desaparece. En 2016, un pequeño equipo de Blue Link Labs liderado por Paul Frazee propuso una alternativa: ¿y si cada usuario se convirtiera en su propio servidor?

Así nació Beaker Browser, un navegador experimental basado en Electron y Chromium que utilizaba el protocolo Hypercore (originalmente Dat) para la publicación de contenido entre pares. Sin backend, sin alojamiento: usted crea un sitio directamente en el navegador y otros usuarios se conectan directamente a su equipo.

El proyecto se archivó en diciembre de 2022, pero sus ideas perduran. Paul Frazee se convirtió en CTO de Bluesky y el propio protocolo Hypercore continúa evolucionando. A continuación descubrirá cómo funcionaba Beaker por dentro, a qué API P2P tenían acceso los desarrolladores web y qué puede sustituirlo hoy. Si está construyendo algo en la web descentralizada, estas lecciones le ahorrarán semanas de ensayo y error.

💡 Resumen rápido:

• Instale Beaker desde las publicaciones de GitHub para Windows, macOS o Linux. Las compilaciones binarias siguen disponibles, sin necesidad de alojamiento aparte.

• Haga clic en «Create New Site» y el navegador genera un sitio con una dirección hyper:// directamente en su equipo. Sin DNS, nginx ni despliegue.

• Edite los archivos en el editor de código integrado y en Hyperdrive, comparta la dirección hyper:// con otro usuario de Beaker y este se conectará a usted directamente.

• El proyecto se cerró en 2022: la red está prácticamente vacía. Para experimentos funcionales con Hypercore, consulte Agregore y Peersky Browser.

Cómo Beaker Browser reinventó la web

Beaker no era solo un envoltorio de Chromium con soporte para torrents. Era un navegador completo que añadía una nueva capa a la plataforma web: la capacidad de leer y escribir archivos directamente en una red entre pares.

Cuando usted visitaba un sitio con el protocolo hyper://, Beaker cargaba sus archivos desde los equipos de otros usuarios que ya habían visitado ese sitio. Tras la descarga, usted mismo comenzaba a compartir los archivos, ya fuera temporalmente mientras la página permanecía abierta o de forma permanente si activaba la compartición. Era similar a BitTorrent, pero integrado directamente en el navegador y vinculado a direcciones web.

Seis funcionalidades que hacían que valiera la pena instalar Beaker

Publicación instantánea de sitios. Usted hacía clic en «Create New Site» y Beaker generaba un sitio con una dirección hyper://. El sitio quedaba disponible de inmediato en la red; cualquiera con Beaker podía abrirlo si conocía la dirección. Sin configuración de DNS, nginx ni despliegue.

Alojamiento colaborativo.** Cuantos más visitantes llegaban a un sitio P2P, más rápido cargaba, porque cada visitante ayudaba a distribuir el contenido. Esto reducía la carga para el autor: no se necesitaba un servidor potente durante los picos de tráfico, la red se escalaba sola.

Aplicaciones P2P con tecnologías web. Beaker proporcionaba la API de JavaScript beaker.hyperdrive para leer y escribir en un sistema de archivos entre pares. Esto significaba que una aplicación web podía almacenar datos no en un servidor, sino en una red descentralizada, y los usuarios controlaban sus propios archivos.

El sistema de archivos Hyperdrive. Cada sitio en Beaker no era solo un conjunto de páginas, sino un sistema de archivos completo con versionado. Usted podía explorar la estructura del sitio como en un gestor de archivos, ver el historial de cambios e incluso bifurcar los proyectos de otras personas, de forma similar a GitHub pero para toda la web.

Terminal integrada. Beaker incluía Webterm, un entorno de línea de comandos directamente en el navegador. Los desarrolladores podían ejecutar scripts, gestionar archivos e interactuar con las API sin salir de la ventana del navegador.

Editor de código fuente. El editor integrado le permitía modificar el HTML, CSS y JavaScript del sitio y ver el resultado de inmediato, en paralelo con la página abierta. Una idea similar a los IDE modernos en línea, pero para la web descentralizada.

Trabajar con la API de Hypercore: ejemplos de código

Beaker añadió un espacio de nombres beaker al objeto global window con varias API clave. Repasemos las principales; todo el código ha sido verificado con la documentación del proyecto.

Trabajar con el sistema de archivos de Hyperdrive

La API beaker.hyperdrive proporcionaba acceso directo a los archivos de sitios P2P. Así era como se creaba una unidad, se escribía y se leía:

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

Los métodos son intuitivos y similares al módulo fs de Node.js: writeFile, readFile, stat, unlink, readdir. La diferencia es que los datos no se escriben en el disco local, sino en la red entre pares, y cualquier otro usuario con acceso a esta unidad puede leerlos.

Consultar el sistema de archivos

La API beaker.hyperdrive.query permitía buscar archivos por patrón en varios sitios simultáneamente. Esto abría la puerta a feeds descentralizados, motores de búsqueda y redes sociales sin un servidor central:

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
}

Una sola llamada y usted obtiene una lista de publicaciones ordenadas por tiempo de los microblogs de todos los sitios en el arreglo sites. Sin claves de API, sin OAuth, sin infraestructura de servidor.

Mensajes entre pares

La API beaker.peersockets proporcionaba comunicación directa entre usuarios del sitio, similar a WebSocket pero funcionando sobre la red 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, 'says:', message)
6
})
7
 
8
function sendToPeer(peerId, message) {
9
  const encoded = new TextEncoder('utf-8').encode(message)
10
  topic.send(peerId, encoded)
11
}

Esta API permitía construir chats descentralizados, editores colaborativos y aplicaciones en tiempo real donde los mensajes van directamente de usuario a usuario sin un servidor intermediario.

Por qué se cerró el proyecto: tres lecciones de Beaker Browser

El 27 de diciembre de 2022, el repositorio de Beaker fue archivado oficialmente con una nota de Paul Frazee: «Ha llegado el momento». Se trasladó a Bluesky, una red social descentralizada donde el Protocolo AT resuelve problemas similares pero a un nivel diferente.

Hubo varias razones para el cierre. Primero, la web P2P nunca superó la fase de experimentación. El usuario promedio no está listo para usar un navegador que no admite extensiones, no sincroniza marcadores y no funciona con sitios conocidos sin salvedades. Segundo, el problema del arranque en frío para una red entre pares resultó ser duro: si el autor del sitio está desconectado y otros visitantes no están sirviendo los datos, el sitio no está disponible. Tercero, Chromium resultó ser una base demasiado pesada para un navegador de nicho: mantener un fork con API personalizadas requería recursos que un equipo de tres personas no tenía.

Pero las lecciones de Beaker son más valiosas que el navegador en sí. El proyecto demostró que un navegador puede ser no solo una ventana a la web, sino un entorno de desarrollo completo. Que hyper:// como protocolo tiene derecho a existir. Y que las API descentralizadas (beaker.hyperdrive, beaker.peersockets) pueden ser tan convenientes como fetch o localStorage.

Video: Beaker Browser en acción

Vea una demostración de Beaker por Paul Frazee, una grabación de 2017 donde muestra la creación de un sitio P2P en tiempo real:

En 5 minutos, el video explica con más claridad que cualquier palabra cómo funcionaba la publicación instantánea y por qué la idea era poderosa.

Lo que vino después: Agregore y otros navegadores P2P

El espíritu de Beaker no murió. Hoy varios proyectos continúan la idea de un navegador para la web descentralizada:

Agregore Browser es un navegador minimalista para la web distribuida, compatible con los protocolos IPFS, Hypercore y BitTorrent de serie. A diferencia de Beaker, Agregore no arrastra todo Chromium, sino que está construido sobre Electron ligero con un enfoque en protocolos P2P. Las extensiones de la tienda web son compatibles y los sitios HTTP funcionan como siempre. El proyecto tiene más de 900 estrellas en GitHub y se actualiza activamente.

Peersky Browser es otro navegador P2P experimental con soporte para IPFS, Hypercore y Web3. Peersky añade su propio conjunto de aplicaciones P2P (peersky://p2p/) y se enfoca en la integración con datos en cadena. El proyecto es más joven que Agregore pero se desarrolla en la misma dirección: el navegador como plataforma para la web descentralizada.

El protocolo Hypercore en sí continúa viviendo de forma independiente a cualquier navegador: impulsa Keet (videollamadas P2P de los creadores del protocolo) y otras aplicaciones descentralizadas.

⁉️🤔 Preguntas frecuentes

¿Se puede descargar y ejecutar Beaker Browser ahora?

Las compilaciones binarias todavía están disponibles en la página de releases de GitHub para Windows, macOS y Linux. El navegador se iniciará, pero la red P2P está prácticamente vacía: la mayoría de los pares están desconectados y los sitios no están disponibles. Para experimentar con el protocolo Hypercore, debería considerar Agregore o Keet en su lugar.

Sí, los archivos de instalación siguen en GitHub Releases. Pero hoy no tiene sentido práctico instalarlo: la red Beaker está muerta, la documentación en docs.beakerbrowser.com no está disponible y el proyecto no ha recibido actualizaciones de seguridad desde 2022. Para entender el concepto, el código fuente en GitHub y las demostraciones en video son suficientes.

¿En qué se diferenciaba Beaker de un navegador normal con una extensión de torrent?

Beaker era una plataforma completa, no un complemento. Una extensión de torrent solo descarga archivos, mientras que Beaker ofrecía a los sitios una API de JavaScript para leer, escribir, buscar en el sistema de archivos y enviar mensajes directos entre usuarios. Todo esto funcionaba como parte de la plataforma web, no como un plugin externo.

Un navegador normal con un cliente de torrent le permite descargar un archivo mediante un enlace magnet. Beaker iba más lejos: un sitio en hyper:// podía buscar contenido en otros sitios usando beaker.hyperdrive.query() e intercambiar mensajes con los visitantes usando beaker.peersockets. Este es un nivel de integración diferente: P2P no era una característica del navegador, sino la base de la plataforma web.

¿Funcionaba Beaker con sitios HTTP normales?

Sí, completamente. Beaker estaba construido sobre Chromium y abría correctamente cualquier sitio HTTP/HTTPS. El problema era el inverso: los navegadores normales no admitían el protocolo hyper://, por lo que los sitios P2P eran invisibles para el 99,9% de los usuarios de internet. Esta fue una de las razones por las que el proyecto no despegó.

La compatibilidad era unidireccional. Usted podía usar Beaker como un navegador normal para toda la web, pero el sitio P2P que creara solo era visible para otros usuarios de Beaker. La adopción masiva requería o bien soporte para hyper:// en Chrome y Firefox, o bien pasarelas como Hashbase que tradujeran los sitios P2P a HTTP. Ninguna de las dos cosas ocurrió a escala suficiente.

¿Qué pasó con Paul Frazee y el equipo de Blue Link Labs?

Paul Frazee se convirtió en CTO de Bluesky, una red social descentralizada construida sobre el Protocolo AT. En una publicación en Bluesky, explica que la experiencia de Beaker influyó directamente en la arquitectura del Protocolo AT. Blue Link Labs dejó de existir. La segunda figura clave del proyecto, Tara Vancil, escribió una emotiva publicación «A Fond Farewell to Beaker» sobre los altibajos del proyecto.

Técnicamente, Frazee no abandonó la descentralización, sino que se movió a un nivel diferente. En lugar de un navegador para la web P2P, está construyendo un protocolo para una red social descentralizada. El Protocolo AT en Bluesky resuelve muchos problemas que hicieron tropezar a Beaker: un modelo federado en lugar de puramente par a par, separación clara entre servidores y clientes, y soporte para escalado.

¿Vale la pena estudiar Beaker hoy?

Como base de código, sí. El código fuente en GitHub muestra cómo integrar un protocolo P2P en una aplicación Electron, cómo diseñar una API para un sistema de archivos descentralizado y cómo construir extensiones de navegador con protocolos personalizados. Como producto, no, pero como proyecto educativo sobre tecnologías descentralizadas, absolutamente.

El código fuente de Beaker representa 6.752 estrellas en GitHub y docenas de repositorios con experimentos en torno al protocolo Hypercore. Para un desarrollador interesado en tecnologías P2P, esto es un tesoro de decisiones arquitectónicas: desde el manejo de protocolos personalizados en Electron hasta la construcción de registros de solo anexión basados en Hypercore.

¿Vale la pena mirar atrás a Beaker en 2026?

Beaker Browser no se volvió masivo. Pero demostró que un modelo web alternativo es posible: un modelo donde el usuario no está separado del servidor por una pila de CDNs, balanceadores de carga y pasarelas de API, sino que es en sí mismo un nodo de la red.

Las ideas de Beaker migraron a Bluesky, el protocolo Hypercore sigue vivo en Keet y otros proyectos, y Agregore Browser continúa hoy el experimento con un navegador P2P multiprotocolo. Si usted es desarrollador web y quiere entender hacia dónde se dirige la web descentralizada, comience por el código fuente de Beaker en GitHub y el activo Agregore.

El experimento no tuvo éxito, pero la idea en sí resultó contagiosa. Y eso quizá sea más importante que el éxito de mercado.