Migração do projeto Dillo do GitHub

 (dillo-browser.org)
2 pontos por GN⁺ 2025-12-01 | 1 comentários | Compartilhar no WhatsApp
  • O projeto do navegador Dillo está em processo de migração para um servidor próprio em vez do GitHub
  • Entre os principais motivos da migração foram citadas a dependência de JavaScript, estrutura de controle único e desempenho lento do GitHub
  • O novo servidor é operado no domínio dillo-browser.org e usa o frontend Git leve baseado em cgit junto com o rastreador de bugs desenvolvido internamente ‘buggy’
  • Todos os dados são gerenciados como repositórios Git e espelhados no Codeberg e Sourcehut, minimizando o risco de perda de dados
  • Foi projetado para manter a confiabilidade mesmo em caso de perda de DNS por meio de assinatura OpenPGP, reforçando a independência e a sustentabilidade do projeto

Contexto

  • O site original do Dillo antes era dillo.org e incluía repositório Mercurial, servidor de e-mail, rastreador de bugs e arquivo de lista de discussão
    • Em 2022, perderam o domínio e terceiros abriram um site semelhante repleto de anúncios de IA
    • Parte do conteúdo foi recuperada, mas não totalmente
  • Com base nessa experiência, decidiram evitar a dependência de um único site e construir uma estrutura de backup distribuída
  • Inicialmente, enviaram o código para o GitHub, mas decidiram que não era ideal a longo prazo

Problemas do GitHub

  • O GitHub foi útil para fluxo de CI e gerenciamento de repositórios, mas possui várias limitações
    • O frontend não funciona sem JavaScript, então não é possível visualizar issues ou PRs no navegador Dillo
    • As páginas consomem recursos excessivamente, criando carga desnecessária para renderizar HTML simples
  • Existe o risco de bloqueio da conta por uma entidade única de controle, o que pode impedir o acesso aos dados
  • A plataforma está ficando cada vez mais lenta e exigindo conexão de internet mais rápida
  • O modelo de notificação por “push” do GitHub não se alinha com o desenvolvimento voltado ao modo offline
  • A falta de ferramentas de gestão comunitária em projetos com alta proporção de usuários não desenvolvedores aumenta a fadiga de manutenção
  • Conforme o GitHub passou a se concentrar em LLM e IA generativa, sites começaram a reforçar muros de JavaScript ou fingerprinting de navegador para barrar crawlers de LLM
    • Isso gerou efeito colateral de bloqueio do acesso de usuários do Dillo

Construção da infraestrutura própria

  • Os serviços tradicionais de repositório não conseguem ao mesmo tempo eliminar o ponto único de falha e operar com baixa sobrecarga
    • Por isso, decidiram operar em servidor próprio e manter vários espelhos
  • Compraram o domínio dillo-browser.org e montaram um pequeno VPS
    • Está operando de forma mais estável do que o esperado, tratando principalmente tráfego de bots de IA
  • Escolheram o cgit como frontend Git
    • Escrito em C, com baixo consumo de RAM e CPU, e funciona sem JavaScript
    • Ajustaram o CSS para funcionar bem no Dillo
    • Acesse em https://git.dillo-browser.org/
  • O rastreador de bugs usa o ‘buggy’, desenvolvido internamente
    • Converte arquivos Markdown em páginas HTML, e cada bug é armazenado em repositórios Git
    • Ganchos do Git atualizam as páginas automaticamente a cada commit
    • Possui edição offline, sem preocupação de vulnerabilidade de segurança
    • Confira em https://bug.dillo-browser.org/
  • O arquivo da lista de discussão está distribuído em 3 serviços externos, e há previsão de adicionar uma cópia própria no futuro

Configuração de espelhos

  • Todos os dados essenciais são gerenciados em formato de repositório Git e estão espelhados no Codeberg e Sourcehut
    • Caso um repositório seja interrompido, é possível mover os dados para outro espelho com baixo custo de transição
  • O ponto único de falha é o DNS (dillo-browser.org)
    • Em caso de perda de DNS, é possível avisar usuários por lista de discussão, Fediverse, IRC e outros canais
    • Como os dados estão replicados em Git, não há perda crítica

Assinatura OpenPGP

  • Esta página é assinada com a chave GPG de Rodrigo Arias Mallo (32E65EC501A1B6FDF8190D293EE6BA977EB2A253)
    • É a mesma chave da versão mais recente do Dillo e também está registrada na conta do GitHub
    • O arquivo de assinatura (index.html.asc) é linkado por <link rel=signature>
  • A assinatura OpenPGP pode manter a confiança mesmo se houver perda de DNS
    • Em vez de cadeia de certificados TLS, a propriedade é comprovada por confiança baseada em assinatura
    • Incluir a assinatura em todos os espelhos Git fortalece a resistência à perda de dados

Andamento e perspectiva da migração

  • O repositório do GitHub não será excluído imediatamente e continuará recebendo atualizações até o fim da migração
    • Após a conclusão, ele será colocado no estado ‘archived’ e um anúncio oficial será feito no site
    • Commits e arquivos de release existentes serão mantidos para preservar compatibilidade com builds anteriores
  • A nova infraestrutura pode operar de forma independente com baixo custo e baixo consumo de energia
    • Com base nas atuais doações e custo de servidor, é possível manter por no mínimo 3 anos
    • Se quiser apoiar, pode fazer doações via Liberapay (https://liberapay.com/dillo/)

Leituras relacionadas

1 comentários

 
GN⁺ 2025-12-01
Comentários do Hacker News

  • Há alguns anos uso o GitLab como alternativa self-hosted. Gosto dele, mas consome muitos recursos
    Recentemente estou testando o Forgejo, feito pela equipe do Codeberg, e ele é realmente excelente
    A maior diferença é o uso de memória. O GitLab é baseado em Ruby on Rails, então vários serviços rodam ao mesmo tempo, enquanto o Forgejo tem uma estrutura de binário único escrita em Go
    O GitLab acaba consumindo toda a memória de uma VM com 16 GB aos poucos, mas o Forgejo usa só uns 300 MB mesmo rodando o servidor e o runner juntos
    Não tem GraphQL, mas a API REST parece mais do que suficiente
    Não entendo muito bem a diferença entre gitea e forgejo, mas vendo a documentação comparativa do Forgejo, parece que houve um soft fork em 2022 por questões de governança

    • Nosso estúdio tem cerca de 50 usuários usando git diariamente, e há 2 anos migramos completamente para o Forgejo
      Por causa da estrutura simples baseada em Go, a manutenção e o custo são muito baixos. Também construímos ferramentas internas diretamente em cima do Forgejo
      Como hospedamos on-premises, desenvolvimento e CI não param mesmo se a internet cair. Ele também suporta cache de gerenciadores de pacotes, o que facilita o gerenciamento de dependências
    • Em facilidade de manutenção, o gitea é imbatível. Uso há mais de 5 anos, e atualizar é só fazer pull da nova versão e reiniciar o daemon
      Teve 10 vezes menos downtime do que o GitHub, e a maior parte ainda foi manutenção planejada
      Quando vejo alguém dizendo que a disponibilidade do GitHub é melhor, eu rio
    • Para projetos pessoais, acho que só um servidor SSH e o sistema de arquivos já bastam
      Ao criar um novo repositório, resolve com git init --bare
      e os backups também rodam automaticamente
      Se você desenvolve sozinho, parece que nem precisa de UI
    • Olhando a documentação de conceitos básicos do Forgejo Actions, o sistema de CI parece bem organizado
      Acho o CI no estilo do GitLab muito melhor do que o GitHub Actions; o GitHub virou padrão pela popularidade, mas o design deixa a desejar
    • Se quiser uma alternativa ainda mais minimalista, também existe o Gerrit. É um app Java sem dependência de banco de dados externo, e guarda configuração e informações de runtime em um repositório git
      Só com um sistema de arquivos compartilhado já fica fácil escalar e fazer backup

  • Eu administro um clube de matemática na região, e usamos o Forgejo quando as crianças entregam tarefas de LaTeX e Python
    Como é fácil gerenciar login e redefinir senha, ele também é muito útil para fins educacionais

  • Concordo com a opinião de que o modelo de notificações push do GitHub é ruim e que seria melhor ver atualizações só quando eu mesmo fosse checar
    Usando filtros de e-mail, dá para transformar as notificações push em algo como um modelo pull. Basta juntar as notificações em uma pasta dedicada e olhar quando quiser

    • Ainda assim, se isso não te satisfaz, dá para usar o sistema de notificações da própria UI do GitHub. Sinceramente, parece mais um problema inventado para procurar problema

  • Achei interessante a história de alguém que criou o próprio rastreador de bugs simples, o “buggy”. Pelo que entendi, é uma ferramenta em C que faz parse de Markdown e gera páginas HTML
    O espírito hacker está vivo

    • Mas acho que quase ninguém seguiria por esse caminho. No meu caso, eu só criaria mais problemas
    • É uma abordagem com vantagens e desvantagens

  • Teve uma pergunta sobre a diferença entre “modelo push” e “modelo pull”

    • Acho que isso se refere a workflows baseados em e-mail, como no Source Hut ou no kernel Linux. Dá para baixar patches localmente via IMAP e trabalhar offline também
    • O push traz aquela pressão de tempo de “faça isso agora”, enquanto o pull é uma diferença na forma de gerenciar o tempo, checando no ritmo que eu determinar

  • Acho que agora estamos numa fase de diáspora em que várias alternativas ao GitHub estão surgindo ao mesmo tempo
    Talvez em alguns meses uma delas acabe se consolidando como principal. Se uma empresa ou figura conhecida lançar uma nova plataforma, também pode acabar liderando o mercado

    • Esse movimento já existe há uns 10 anos. Antes foi a fase de migração para o GitLab, e mesmo hoje a discoverability do GitHub continua sendo incomparável
      São pouquíssimos os projetos que deixam o GitHub, então ainda acho cedo para isso
    • Como cada desenvolvedor colabora de um jeito diferente, é difícil convergir para uma solução única
      Na verdade, está acontecendo uma re-descentralização. Estamos entrando numa era em que cada um escolhe a forge que combina com seu controle, sua jurisdição e seu workflow
    • Daqui para frente, o objetivo é ir para uma estrutura federada, e não centralizada como o GitHub. Assim não ficamos dependentes de uma única entidade
    • A questão importante é se queremos “um único substituto” ou se queremos evitar repetir exatamente a mesma situação daqui a 5 anos
    • É exatamente isso que estamos tentando fazer. Estamos preparando uma plataforma de colaboração com foco em indies chamada Tangled, e em breve teremos um grande anúncio

  • Quero convidar o projeto Dillo para o Tangled → tangled.org

    • É impressionante como funciona bem mesmo sem JavaScript
    • Seria legal se também suportasse sistemas de controle de versão além de Git

  • Acho que o maior problema do GitHub é a lentidão crescente da usabilidade

    • Fiquei em dúvida se a expressão “more and more slow” soa natural. “slower and slower” seria mais comum?
    • Antes era ok, mas ultimamente o carregamento das páginas está lento demais. Acho que não é só por causa do React
      Para explorar código eu uso o github.dev, mas PRs e Actions continuam lentos e frustrantes

  • Se você quiser instalar o Forgejo em uma VM, eu criei um script que configura servidor e runner de uma vez só → easyforgejo

  • Não tenho especialidade nesse assunto, mas achei a leitura interessante
    Fiquei surpreso com a quantidade de fatores envolvidos só para configurar um sistema de controle de versão
    Eu uso Fossil, e para organizações pequenas, quando a mesma pessoa acumula funções de desenvolvedor, administrador de sistemas e suporte, ele é muito mais simples
    As restrições de deploy key do GitHub também são incômodas. Quando você opera vários apps e servidores, ter de configurar uma chave separada para cada um dá bastante trabalho