O que é o Beaker Browser e porque é que ainda se fala dele

A internet como a conhecemos assenta numa arquitetura cliente-servidor. Escreve um endereço, o browser vai a um servidor algures num centro de dados da AWS ou da Cloudflare, obtém o HTML e renderiza a página. Se o servidor cair, o site desaparece. Em 2016, uma pequena equipa da Blue Link Labs liderada por Paul Frazee propôs uma alternativa: e se cada utilizador se tornasse o seu próprio servidor?

Foi assim que surgiu o Beaker Browser, um browser experimental baseado em Electron e Chromium que usava o protocolo Hypercore (originalmente Dat) para a publicação de conteúdos ponto a ponto. Sem backend, sem alojamento: cria-se um site diretamente no browser e os outros utilizadores ligam-se diretamente ao seu computador.

O projeto foi arquivado em dezembro de 2022, mas as suas ideias perduram. Paul Frazee tornou-se CTO da Bluesky e o próprio protocolo Hypercore continua a evoluir. A seguir verá como o Beaker funcionava internamente, a que APIs P2P os programadores web tinham acesso e o que o pode substituir hoje. Se está a construir algo na web descentralizada, estas lições vão poupar-lhe semanas de tentativa e erro.

💡 Visão geral rápida:

• Instale o Beaker a partir dos lançamentos no GitHub para Windows, macOS ou Linux. As compilações binárias ainda estão disponíveis, sem necessidade de alojamento separado.

• Clique em «Create New Site» e o browser gera um site com um endereço hyper:// diretamente no seu computador. Sem DNS, nginx ou deployment.

• Edite os ficheiros no editor de código integrado e no Hyperdrive, partilhe o endereço hyper:// com outro utilizador do Beaker e este liga-se a si diretamente.

• O projeto foi encerrado em 2022: a rede está praticamente vazia. Para experiências funcionais com o Hypercore, veja o Agregore e o Peersky Browser.

Como o Beaker Browser reinventou a web

O Beaker não era apenas um invólucro do Chromium com suporte para torrents. Era um browser completo que acrescentava uma nova camada à plataforma web: a capacidade de ler e escrever ficheiros diretamente numa rede ponto a ponto.

Quando visitava um site com o protocolo hyper://, o Beaker carregava os seus ficheiros a partir dos computadores de outros utilizadores que tinham visitado esse site. Após o download, o próprio utilizador passava a partilhar os ficheiros, temporariamente enquanto a página estivesse aberta ou permanentemente se ativasse a partilha. Era semelhante ao BitTorrent, mas integrado no browser e associado a endereços web.

Seis funcionalidades que faziam valer a pena instalar o Beaker

Publicação instantânea de sites. Clicava em «Create New Site» e o Beaker gerava um site com um endereço hyper://. O site ficava imediatamente disponível na rede; qualquer pessoa com o Beaker podia abri-lo se soubesse o endereço. Sem configuração de DNS, nginx ou deployment.

Alojamento colaborativo. Quanto mais visitantes chegavam a um site P2P, mais rápido ele carregava, porque cada visitante ajudava a distribuir o conteúdo. Isto reduzia a carga sobre o autor: não era necessário um servidor potente durante os picos de tráfego, a própria rede escalava.

Aplicações P2P com tecnologias web. O Beaker disponibilizava a API JavaScript beaker.hyperdrive para ler e escrever num sistema de ficheiros ponto a ponto. Isto significava que uma aplicação web podia armazenar dados não num servidor, mas numa rede descentralizada, e os utilizadores controlavam os seus próprios ficheiros.

O sistema de ficheiros Hyperdrive. Cada site no Beaker não era apenas um conjunto de páginas, mas um sistema de ficheiros completo com versionamento. Era possível navegar pela estrutura do site como num gestor de ficheiros, ver o histórico de alterações e até bifurcar projetos de outras pessoas, semelhante ao GitHub mas para toda a web.

Terminal integrado. O Beaker incluía o Webterm, um ambiente de linha de comandos diretamente no browser. Os programadores podiam executar scripts, gerir ficheiros e interagir com APIs sem sair da janela do browser.

Editor de código-fonte. O editor integrado permitia editar o HTML, CSS e JavaScript do site e ver o resultado imediatamente, lado a lado com a página aberta. Uma ideia semelhante aos IDE online modernos, mas para a web descentralizada.

Trabalhar com a API Hypercore: exemplos de código

O Beaker adicionou um namespace beaker ao objeto global window com várias APIs essenciais. Vamos analisar as principais; todo o código foi verificado com base na documentação do projeto.

Trabalhar com o sistema de ficheiros Hyperdrive

A API beaker.hyperdrive fornecia acesso direto aos ficheiros de sites P2P. Eis o aspeto da criação de um drive, da escrita e da leitura:

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

Os métodos são intuitivos e semelhantes ao módulo fs do Node.js: writeFile, readFile, stat, unlink, readdir. A diferença é que os dados não são escritos no disco local, mas sim na rede peer-to-peer, e qualquer outro utilizador com acesso a este drive pode lê-los.

Consultar o sistema de ficheiros

A API beaker.hyperdrive.query permitia procurar ficheiros por padrão em vários sites em simultâneo. Isto abriu a porta a feeds descentralizados, motores de busca e redes sociais sem um 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
}

Uma única chamada e obtém-se uma lista de publicações ordenada por data, proveniente dos microblogs de todos os sites no array sites. Sem chaves de API, sem OAuth, sem infraestrutura de servidor.

Mensagens peer-to-peer

A API beaker.peersockets fornecia comunicação direta entre utilizadores do site, semelhante ao WebSocket, mas a funcionar sobre a rede 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 permitia criar chats descentralizados, editores colaborativos e aplicações em tempo real onde as mensagens vão diretamente de utilizador para utilizador, sem um servidor intermediário.

Porque é que o projeto foi encerrado: três lições do Beaker Browser

A 27 de dezembro de 2022, o repositório do Beaker foi oficialmente arquivado com uma nota de Paul Frazee: «Chegou a hora.» Ele mudou-se para o Bluesky, uma rede social descentralizada onde o AT Protocol resolve problemas semelhantes, mas a um nível diferente.

Houve várias razões para o encerramento. Em primeiro lugar, a web P2P nunca passou da experimentação. O utilizador comum não está preparado para usar um navegador que não suporta extensões, não sincroniza marcadores e não funciona com sites conhecidos sem ressalvas. Em segundo lugar, o problema do arranque a frio para uma rede peer-to-peer revelou-se severo: se o autor do site estiver offline e outros visitantes não estiverem a partilhar, o site fica indisponível. Em terceiro lugar, o Chromium revelou-se uma base demasiado pesada para um navegador de nicho: manter um fork com APIs personalizadas exigia recursos que uma equipa de três pessoas não tinha.

Mas as lições do Beaker são mais valiosas do que o próprio navegador. O projeto demonstrou que um navegador pode ser não apenas uma janela para a web, mas um verdadeiro ambiente de desenvolvimento. Que o hyper:// como protocolo tem o direito de existir. E que APIs descentralizadas (beaker.hyperdrive, beaker.peersockets) podem ser tão convenientes como o fetch ou o localStorage.

Vídeo: Beaker Browser em ação

Veja uma demonstração do Beaker por Paul Frazee, uma gravação de 2017 onde ele mostra a criação de um site P2P em tempo real:

Em 5 minutos, o vídeo explica de forma mais clara do que qualquer palavra como funcionava a publicação instantânea e porque é que a ideia era poderosa.

O que veio a seguir: Agregore e outros navegadores P2P

O espírito do Beaker não morreu. Hoje, vários projetos continuam a ideia de um navegador para a web descentralizada:

O Agregore Browser é um navegador minimalista para a web distribuída, com suporte nativo para os protocolos IPFS, Hypercore e BitTorrent. Ao contrário do Beaker, o Agregore não arrasta consigo o Chromium completo, sendo construído sobre o Electron leve, com foco em protocolos P2P. As extensões da loja web são suportadas e os sites HTTP funcionam como habitualmente. O projeto tem mais de 900 estrelas no GitHub e é atualizado ativamente.

O Peersky Browser é outro navegador P2P experimental com suporte para IPFS, Hypercore e Web3. O Peersky adiciona o seu próprio conjunto de aplicações P2P (peersky://p2p/) e foca-se na integração com dados on-chain. O projeto é mais recente do que o Agregore, mas desenvolve-se na mesma direção: o navegador como plataforma para a web descentralizada.

O próprio protocolo Hypercore continua a viver independentemente de qualquer navegador: alimenta o Keet (videochamadas P2P dos criadores do protocolo) e outras aplicações descentralizadas.

⁉️🤔 Perguntas frequentes

É possível descarregar e executar o Beaker Browser agora?

As compilações binárias ainda estão disponíveis na página de lançamentos do GitHub para Windows, macOS e Linux. O navegador inicia, mas a rede P2P está praticamente vazia: a maioria dos pares está offline e os sites estão indisponíveis. Para experiências com o protocolo Hypercore, deve antes considerar o Agregore ou o Keet.

Sim, os ficheiros de instalação ainda estão nos Lançamentos do GitHub. Mas não faz sentido prático instalá-lo hoje: a rede Beaker está morta, a documentação em docs.beakerbrowser.com está indisponível e o projeto não recebe atualizações de segurança desde 2022. Para compreender o conceito, o código-fonte no GitHub e as demonstrações em vídeo são suficientes.

Em que é que o Beaker era diferente de um navegador normal com uma extensão de torrent?

O Beaker era uma plataforma completa, não um extra. Uma extensão de torrent apenas descarrega ficheiros, enquanto o Beaker oferecia aos sites uma API JavaScript para ler, escrever, pesquisar no sistema de ficheiros e enviar mensagens diretas entre utilizadores. Tudo isto funcionava como parte da plataforma web, não como um plugin externo.

Um navegador normal com um cliente de torrent permite-lhe descarregar um ficheiro através de um link magnet. O Beaker foi mais longe: um site em hyper:// podia pesquisar conteúdo noutros sites usando beaker.hyperdrive.query() e trocar mensagens com os visitantes usando beaker.peersockets. Este é um nível diferente de integração: o P2P não era uma funcionalidade do navegador, mas a base da plataforma web.

O Beaker funcionava com sites HTTP normais?

Sim, totalmente. O Beaker foi construído sobre o Chromium e abria corretamente qualquer site HTTP/HTTPS. O problema era o inverso: os navegadores normais não suportavam o protocolo hyper://, pelo que os sites P2P eram invisíveis para 99,9% dos utilizadores da internet. Esta foi uma das razões pelas quais o projeto não vingou.

A compatibilidade era unidirecional. Podia usar o Beaker como um navegador normal para toda a web, mas o site P2P que criasse era visível apenas para outros utilizadores do Beaker. A adoção em massa exigia ou o suporte para hyper:// no Chrome e Firefox, ou gateways como o Hashbase que traduziam sites P2P para HTTP. Nenhum dos cenários aconteceu à escala suficiente.

O que aconteceu a Paul Frazee e à equipa da Blue Link Labs?

Paul Frazee tornou-se CTO da Bluesky, uma rede social descentralizada construída sobre o AT Protocol. Numa publicação no Bluesky, explica que a experiência do Beaker influenciou diretamente a arquitetura do AT Protocol. A Blue Link Labs deixou de existir. A segunda figura-chave do projeto, Tara Vancil, escreveu uma publicação emotiva "A Fond Farewell to Beaker" sobre os altos e baixos do projeto.

Tecnicamente, Frazee não abandonou a descentralização, mas passou para um nível diferente. Em vez de um navegador para a web P2P, está a construir um protocolo para uma rede social descentralizada. O AT Protocol no Bluesky resolve muitos problemas que fizeram tropeçar o Beaker: um modelo federado em vez de puramente peer-to-peer, separação clara entre servidores e clientes, suporte para escalabilidade.

Faz algum sentido estudar o Beaker hoje?

Como base de código, sim. O código-fonte no GitHub mostra como integrar um protocolo P2P numa aplicação Electron, como desenhar uma API para um sistema de ficheiros descentralizado e como construir extensões de navegador com protocolos personalizados. Como produto, não, mas como projeto educativo sobre tecnologias descentralizadas, absolutamente.

O código-fonte do Beaker representa 6.752 estrelas no GitHub e dezenas de repositórios com experiências em torno do protocolo Hypercore. Para um programador interessado em tecnologias P2P, este é um tesouro de decisões arquitetónicas: desde o tratamento de protocolos personalizados no Electron até à construção de registos apenas de acréscimo baseados no Hypercore.

Vale a pena olhar para trás para o Beaker em 2026

O Beaker Browser não se tornou mainstream. Mas mostrou que um modelo alternativo de web é possível: um modelo onde o utilizador não está separado do servidor por uma pilha de CDNs, balanceadores de carga e gateways de API, mas é ele próprio um nó na rede.

As ideias do Beaker migraram para o Bluesky, o protocolo Hypercore continua vivo no Keet e noutros projetos, e o Agregore Browser prossegue hoje a experiência de um navegador P2P multiprotocolo. Se é programador web e quer perceber para onde caminha a web descentralizada, comece pelo código-fonte do Beaker no GitHub e pelo ativo Agregore.

A experiência não resultou, mas a ideia em si revelou-se contagiosa. E isso talvez seja mais importante do que o sucesso comercial.