Qu’est-ce que Beaker Browser et pourquoi on en parle encore

L’internet tel que nous le connaissons repose sur une architecture client-serveur. Vous tapez une adresse, le navigateur interroge un serveur hébergé dans un datacenter AWS ou Cloudflare, récupère le HTML et affiche la page. Si le serveur tombe, le site disparaît. En 2016, une petite équipe de Blue Link Labs dirigée par Paul Frazee a proposé une alternative: et si chaque utilisateur devenait son propre serveur?

C’est ainsi qu’est né Beaker Browser, un navigateur expérimental basé sur Electron et Chromium qui utilisait le protocole Hypercore (initialement Dat) pour la publication de contenu en pair-à-pair. Pas de backend, pas d’hébergement: vous créez un site directement dans le navigateur, et les autres utilisateurs se connectent directement à votre ordinateur.

Le projet a été archivé en décembre 2022, mais ses idées continuent de vivre. Paul Frazee est devenu CTO de Bluesky, et le protocole Hypercore lui-même poursuit son évolution. Vous trouverez ci-dessous comment Beaker fonctionnait sous le capot, à quelles API P2P les développeurs web avaient accès, et par quoi le remplacer aujourd’hui. Si vous construisez quelque chose sur le web décentralisé, ces enseignements vous feront gagner des semaines d’essais et d’erreurs.

💡 Aperçu rapide:

• Installez Beaker depuis les releases GitHub pour Windows, macOS ou Linux. Les builds binaires sont toujours disponibles, aucun hébergement séparé n’est nécessaire.

• Cliquez sur «Create New Site» et le navigateur génère un site avec une adresse hyper:// directement sur votre ordinateur. Pas de DNS, de nginx ni de déploiement.

• Modifiez les fichiers dans l’éditeur de code intégré et Hyperdrive, partagez l’adresse hyper:// avec un autre utilisateur de Beaker, et il se connecte directement à vous.

• Le projet a été fermé en 2022: le réseau est presque vide. Pour des expérimentations fonctionnelles avec Hypercore, regardez du côté d’Agregore et de Peersky Browser.

Comment Beaker Browser a réinventé le web

Beaker n’était pas un simple wrapper Chromium avec un support torrent. C’était un navigateur à part entière qui ajoutait une nouvelle couche à la plateforme web: la capacité de lire et d’écrire des fichiers directement sur un réseau pair-à-pair.

Lorsque vous visitiez un site avec le protocole hyper://, Beaker chargeait ses fichiers depuis les ordinateurs des autres utilisateurs ayant visité ce site. Après le téléchargement, vous commenciez vous-même à partager les fichiers, soit temporairement pendant que la page était ouverte, soit de façon permanente si vous activiez le partage. Cela ressemblait à BitTorrent, mais intégré directement dans le navigateur et lié aux adresses web.

Six fonctionnalités qui justifiaient d’installer Beaker

Publication instantanée de site. Vous cliquiez sur «Create New Site» et Beaker générait un site avec une adresse hyper://. Le site était immédiatement disponible sur le réseau; toute personne disposant de Beaker pouvait l’ouvrir si elle connaissait l’adresse. Aucune configuration DNS, pas de nginx ni de déploiement.

Hébergement collaboratif. Plus il y avait de visiteurs sur un site P2P, plus il se chargeait vite, car chaque visiteur contribuait à distribuer le contenu. Cela réduisait la charge pour l’auteur: aucun serveur puissant n’était nécessaire lors des pics de trafic, le réseau s’adaptait de lui-même.

Applications P2P utilisant les technologies web. Beaker fournissait l’API JavaScript beaker.hyperdrive pour lire et écrire dans un système de fichiers pair-à-pair. Cela signifiait qu’une application web pouvait stocker ses données non pas sur un serveur mais dans un réseau décentralisé, et les utilisateurs contrôlaient leurs propres fichiers.

Le système de fichiers Hyperdrive. Chaque site dans Beaker n’était pas seulement un ensemble de pages mais un véritable système de fichiers avec gestion de versions. Vous pouviez parcourir la structure du site comme dans un gestionnaire de fichiers, consulter l’historique des modifications, et même forker les projets d’autres personnes, un peu comme GitHub mais pour l’ensemble du web.

Terminal intégré. Beaker incluait Webterm, un environnement de ligne de commande directement dans le navigateur. Les développeurs pouvaient exécuter des scripts, gérer des fichiers et interagir avec les API sans quitter la fenêtre du navigateur.

Éditeur de code source. L’éditeur intégré vous permettait de modifier le HTML, le CSS et le JavaScript du site et de voir le résultat immédiatement, côte à côte avec la page ouverte. Une idée proche des IDE en ligne modernes, mais pour le web décentralisé.

Travailler avec l’API Hypercore: exemples de code

Beaker ajoutait un espace de noms beaker à l’objet global window avec plusieurs API clés. Passons en revue les principales; tout le code a été vérifié par rapport à la documentation du projet.

Travailler avec le système de fichiers Hyperdrive

L’API beaker.hyperdrive donnait un accès direct aux fichiers des sites P2P. Voici à quoi ressemblaient la création d’un disque, l’écriture et la lecture:

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

Les méthodes sont intuitives et proches du module fs de Node.js: writeFile, readFile, stat, unlink, readdir. La différence est que les données ne sont pas écrites sur le disque local, mais sur le réseau pair-à-pair, et tout autre utilisateur ayant accès à ce disque peut les lire.

Interroger le système de fichiers

L’API beaker.hyperdrive.query permettait de rechercher des fichiers par motif sur plusieurs sites simultanément. Cela ouvrait la voie aux flux décentralisés, aux moteurs de recherche et aux réseaux sociaux sans serveur 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
}

Un seul appel, et vous obtenez une liste de publications triée par date, issue des microblogs de tous les sites présents dans le tableau sites. Pas de clé API, pas d’OAuth, pas d’infrastructure serveur.

Messages pair-à-pair

L’API beaker.peersockets offrait une communication directe entre les utilisateurs d’un site, similaire à WebSocket mais fonctionnant sur le réseau 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
}

Cette API permettait de construire des chats décentralisés, des éditeurs collaboratifs et des applications en temps réel où les messages transitent directement d’un utilisateur à l’autre, sans serveur intermédiaire.

Pourquoi le projet a été arrêté: trois leçons de Beaker Browser

Le 27 décembre 2022, le dépôt Beaker a été officiellement archivé avec une note de Paul Frazee: «The time has come.» Il a rejoint Bluesky, un réseau social décentralisé où le protocole AT résout des problèmes similaires, mais à un autre niveau.

Plusieurs raisons expliquent cet arrêt. Premièrement, le web P2P n’a jamais dépassé le stade de l’expérimentation. L’utilisateur moyen n’est pas prêt à utiliser un navigateur qui ne prend pas en charge les extensions, ne synchronise pas les favoris et ne fonctionne pas avec les sites habituels sans restrictions. Deuxièmement, le problème du démarrage à froid pour un réseau pair-à-pair s’est avéré rude: si l’auteur du site est hors ligne et que les autres visiteurs ne partagent pas le contenu, le site est indisponible. Troisièmement, Chromium s’est révélé être une base trop lourde pour un navigateur de niche: maintenir un fork avec des API personnalisées exigeait des ressources qu’une équipe de trois personnes ne possédait pas.

Mais les leçons de Beaker ont plus de valeur que le navigateur lui-même. Le projet a démontré qu’un navigateur peut être non seulement une fenêtre sur le web, mais aussi un véritable environnement de développement. Que le protocole hyper:// a le droit d’exister. Et que des API décentralisées (beaker.hyperdrive, beaker.peersockets) peuvent être aussi pratiques que fetch ou localStorage.

Vidéo: Beaker Browser en action

Regardez une démonstration de Beaker par Paul Frazee, un enregistrement de 2017 où il montre la création d’un site P2P en temps réel:

En 5 minutes, la vidéo explique plus clairement que n’importe quel discours comment fonctionnait la publication instantanée et pourquoi l’idée était puissante.

La suite: Agregore et les autres navigateurs P2P

L’esprit de Beaker n’a pas disparu. Aujourd’hui, plusieurs projets poursuivent l’idée d’un navigateur pour le web décentralisé:

Agregore Browser est un navigateur minimaliste pour le web distribué, qui prend en charge nativement les protocoles IPFS, Hypercore et BitTorrent. Contrairement à Beaker, Agregore n’embarque pas l’intégralité de Chromium mais s’appuie sur une version allégée d’Electron, en mettant l’accent sur les protocoles P2P. Les extensions du web store sont prises en charge et les sites HTTP fonctionnent normalement. Le projet totalise plus de 900 étoiles sur GitHub et fait l’objet de mises à jour régulières.

Peersky Browser est un autre navigateur P2P expérimental compatible IPFS, Hypercore et Web3. Peersky propose son propre ensemble d’applications P2P (peersky://p2p/) et se concentre sur l’intégration avec les données on-chain. Le projet est plus jeune qu’Agregore mais évolue dans la même direction: le navigateur comme plateforme pour le web décentralisé.

Le protocole Hypercore lui-même continue de vivre indépendamment de tout navigateur: il alimente Keet (les appels vidéo P2P créés par les auteurs du protocole) ainsi que d’autres applications décentralisées.

⁉️🤔 Foire aux questions

Peut-on encore télécharger et lancer Beaker Browser aujourd’hui?

Les binaires restent disponibles sur la page des releases GitHub pour Windows, macOS et Linux. Le navigateur se lance, mais le réseau P2P est pratiquement vide: la plupart des pairs sont hors ligne et les sites sont inaccessibles. Pour expérimenter avec le protocole Hypercore, mieux vaut se tourner vers Agregore ou Keet.

Oui, les fichiers d’installation sont toujours sur GitHub Releases. Mais il n’y a aucun intérêt pratique à l’installer aujourd’hui: le réseau Beaker est mort, la documentation sur docs.beakerbrowser.com est indisponible et le projet n’a plus reçu de correctif de sécurité depuis 2022. Pour comprendre le concept, le code source sur GitHub et les démonstrations vidéo suffisent.

En quoi Beaker se distinguait-il d’un navigateur classique doté d’une extension torrent?

Beaker était une plateforme complète, pas un module complémentaire. Une extension torrent ne fait que télécharger des fichiers, tandis que Beaker offrait aux sites une API JavaScript pour lire, écrire, parcourir le système de fichiers et échanger des messages directement entre utilisateurs. Tout cela fonctionnait comme une partie intégrante de la plateforme web, pas comme un plugin externe.

Un navigateur classique avec un client torrent vous permet de télécharger un fichier via un lien magnet. Beaker allait plus loin: un site en hyper:// pouvait rechercher du contenu sur d’autres sites avec beaker.hyperdrive.query(), et échanger des messages avec les visiteurs via beaker.peersockets. C’est un niveau d’intégration différent: le P2P n’était pas une fonctionnalité du navigateur, mais le socle de la plateforme web.

Beaker fonctionnait-il avec les sites HTTP classiques?

Oui, parfaitement. Beaker était construit sur Chromium et ouvrait correctement n’importe quel site HTTP/HTTPS. Le problème était inverse: les navigateurs classiques ne prenaient pas en charge le protocole hyper://, de sorte que les sites P2P étaient invisibles pour 99,9% des internautes. C’est l’une des raisons pour lesquelles le projet n’a pas décollé.

La compatibilité était à sens unique. Vous pouviez utiliser Beaker comme un navigateur normal pour tout le web, mais le site P2P que vous créiez n’était visible que par les autres utilisateurs de Beaker. Une adoption de masse aurait nécessité soit la prise en charge du hyper:// dans Chrome et Firefox, soit des passerelles comme Hashbase qui traduisaient les sites P2P en HTTP. Ni l’une ni l’autre n’a atteint une échelle suffisante.

Que sont devenus Paul Frazee et l’équipe de Blue Link Labs?

Paul Frazee est devenu CTO de Bluesky, le réseau social décentralisé fondé sur le protocole AT. Dans un post sur Bluesky, il explique que l’expérience Beaker a directement influencé l’architecture du protocole AT. Blue Link Labs a cessé d’exister. La deuxième figure clé du projet, Tara Vancil, a écrit un billet touchant intitulé «A Fond Farewell to Beaker» sur les hauts et les bas du projet.

Techniquement, Frazee n’a pas abandonné la décentralisation, il est passé à un autre niveau. Au lieu d’un navigateur pour le web P2P, il construit un protocole pour un réseau social décentralisé. Le protocole AT de Bluesky résout plusieurs problèmes qui ont fait trébucher Beaker: un modèle fédéré plutôt que purement pair-à-pair, une séparation claire entre serveurs et clients, et une capacité de montée en charge.

Y a-t-il un intérêt à étudier Beaker aujourd’hui?

En tant que base de code, oui. Le code source sur GitHub montre comment intégrer un protocole P2P dans une application Electron, comment concevoir une API pour un système de fichiers décentralisé et comment construire des extensions de navigateur avec des protocoles personnalisés. En tant que produit, non, mais en tant que projet pédagogique sur les technologies décentralisées, absolument.

Le code source de Beaker représente 6 752 étoiles sur GitHub et des dizaines de dépôts d’expérimentations autour du protocole Hypercore. Pour un développeur qui s’intéresse aux technologies P2P, c’est une mine de décisions architecturales: de la gestion des protocoles personnalisés dans Electron à la construction de journaux en ajout seul basés sur Hypercore.

Est-ce que ça vaut le coup de se pencher sur Beaker en 2026

Beaker Browser n’est pas devenu grand public. Mais il a montré qu’un autre modèle de web est possible: un modèle où l’utilisateur n’est pas séparé du serveur par un empilement de CDN, de répartiteurs de charge et de passerelles API, mais est lui-même un nœud du réseau.

Les idées de Beaker ont migré vers Bluesky, le protocole Hypercore perdure dans Keet et d’autres projets, et le navigateur Agregore poursuit aujourd’hui l’expérience d’un navigateur P2P multi-protocole. Si vous êtes développeur web et souhaitez comprendre où va le web décentralisé, commencez par le code source de Beaker sur GitHub et par le projet actif Agregore.

L’expérience n’a pas réussi, mais l’idée elle-même s’est révélée contagieuse. Et c’est peut-être plus important qu’un succès commercial.