Migration du projet Dillo depuis GitHub

 (dillo-browser.org)
2 points par GN⁺ 2025-12-01 | 1 commentaires | Partager sur WhatsApp
  • Le projet de navigateur web Dillo est en cours de migration depuis GitHub vers un serveur auto-hébergé
  • Les raisons principales de la migration sont la dépendance au JavaScript, la gouvernance centralisée et les performances lentes relevées sur GitHub
  • Le nouveau serveur est exploité sous le domaine dillo-browser.org et utilise un frontend Git léger basé sur cgit ainsi qu’un bug tracker maison, « buggy »
  • Toutes les données sont gérées dans un dépôt Git et répliquées sur Codeberg et Sourcehut, ce qui minimise le risque de perte
  • La conception s’appuie sur des signatures OpenPGP pour préserver la confiance en cas de perte DNS et renforcer l’autonomie et la pérennité du projet

Contexte

  • Le site historique de Dillo était dillo.org, avec un dépôt Mercurial, un serveur de courrier, un bug tracker et les archives de la liste de diffusion
    • En 2022, le domaine a été perdu, puis un tiers a créé un site similaire rempli de publicités IA
    • Certaines données ont été récupérées, mais pas de manière exhaustive
  • Forts de cette expérience, les mainteneurs ont décidé d’éviter une dépendance à un site unique et de bâtir une infrastructure de sauvegarde distribuée
  • Le code a d’abord été déposé sur GitHub, mais jugé inadapté à long terme

Limites de GitHub

  • GitHub était pratique pour les workflows CI et la gestion des dépôts, mais présente plusieurs limites
    • Le frontend ne fonctionne qu’avec le JavaScript, ce qui empêche de consulter les issues et PR avec le navigateur Dillo
    • Les pages consomment trop de ressources, provoquant une surcharge inutile pour un rendu HTML simple
  • Le risque qu’un acteur unique de gouvernance bloque un compte peut entraîner la suppression de l’accès aux données
  • La plateforme ralentit progressivement et exige une connexion Internet rapide
  • Le modèle de notifications de GitHub basé sur le « push model » ne s’adapte pas à un mode de développement orienté hors ligne
  • L’absence d’outils de modération communautaire dans les projets à fort taux d’utilisateurs non développeurs augmente la fatigue des mainteneurs
  • Alors que GitHub s’oriente vers le LLM et l’IA générative, des sites mettent en place des murs JavaScript ou un fingerprinting navigateur renforcé pour bloquer les crawlers LLM
    • Cela provoque des effets de bord qui empêchent l’accès via Dillo

Mise en place d’un hébergement propre

  • Les services de dépôt existants ne permettaient pas de remplir à la fois les objectifs de suppression du point de défaillance unique et d’exploitation légère
    • Nous avons donc choisi d’exploiter un serveur propre et de conserver plusieurs miroirs
  • Le domaine dillo-browser.org a été acquis et un petit VPS a été installé
    • Il fonctionne de manière plus stable que prévu, en traitant principalement le trafic des bots IA
  • Le frontend Git choisi est cgit
    • Écrit en C, il consomme moins de RAM et de CPU, et fonctionne sans JavaScript
    • Le CSS a été ajusté pour s’afficher correctement dans Dillo
    • Accessible via https://git.dillo-browser.org/
  • Le bug tracker utilise « buggy », développé en interne
    • Il parse des fichiers Markdown pour générer des pages HTML, et chaque bug est stocké dans un dépôt Git
    • Lors d’un commit, un hook Git met automatiquement à jour les pages
    • Édition possible hors ligne, sans crainte de vulnérabilités de sécurité
    • Disponible à https://bug.dillo-browser.org/
  • Les archives de la liste de diffusion sont stockées de manière répartie sur 3 services externes, avec ajout prévu d’une copie propre ensuite

Configuration des miroirs

  • Toutes les données critiques sont gérées sous forme de dépôts Git et sont répliquées sur Codeberg et Sourcehut
    • Si un dépôt arrêté, on peut basculer rapidement vers un autre miroir avec un faible coût de migration
  • Le point de défaillance unique reste le DNS (dillo-browser.org)
    • En cas de perte du DNS, il est possible d’informer les utilisateurs via mailing lists, Fediverse, IRC
    • Les données étant répliquées en git, il n’y a pas de perte fatale

Signature OpenPGP

  • Cette page est signée avec la clé GPG de Rodrigo Arias Mallo (32E65EC501A1B6FDF8190D293EE6BA977EB2A253)
    • Il s’agit de la même clé que pour les dernières versions de Dillo, et elle est également enregistrée sur le compte GitHub
    • Le fichier de signature (index.html.asc) est lié par <link rel=signature>
  • La signature OpenPGP permet de conserver la confiance même en cas de perte DNS
    • Prouver la propriété via une confiance basée sur la signature plutôt que par la chaîne de certificats TLS
    • Les signatures incluses dans tous les miroirs Git renforcent la résistance aux pertes de données

Avancement de la migration et perspectives

  • Le dépôt GitHub n’est pas supprimé immédiatement et continuera d’être mis à jour jusqu’à la fin de la migration
    • Une fois terminée, le dépôt sera basculé en mode « archived », avec annonce sur le site officiel
    • Les commits et fichiers de release sont conservés pour la rétro-compatibilité descendante
  • La nouvelle infrastructure peut être exploitée de manière indépendante avec peu de coûts et de consommation énergétique
    • Au vu du niveau actuel des dons et des coûts serveur, elle peut être maintenue au moins pendant 3 ans
    • Les soutiens sont possibles via Liberapay si vous le souhaitez : https://liberapay.com/dillo/

À lire aussi

1 commentaires

 
GN⁺ 2025-12-01
Commentaire Hacker News

  • J’utilise GitLab comme alternative auto-hébergée depuis plusieurs années. J’aime bien, mais ça consomme énormément de ressources
    En ce moment, je teste Forgejo, créé par l’équipe de Codeberg, et c’est vraiment excellent
    La plus grande différence, c’est l’utilisation de la mémoire. GitLab repose sur Ruby on Rails, donc plusieurs services tournent en même temps, alors que Forgejo est structuré comme un binaire unique écrit en Go
    GitLab finit par utiliser progressivement toute la mémoire d’une VM de 16 Go, tandis que Forgejo n’utilise qu’environ 300 Mo même avec le serveur et le runner lancés ensemble
    Il n’y a pas de GraphQL, mais l’API REST semble largement suffisante
    Je ne connais pas très bien la différence entre gitea et forgejo, mais d’après le document de comparaison de Forgejo, cela semble être un soft fork lancé en 2022 à cause de problèmes de gouvernance

    • Dans notre studio, une cinquantaine d’utilisateurs utilisent git tous les jours, et nous avons entièrement migré vers Forgejo il y a deux ans
      Grâce à sa structure simple basée sur Go, la maintenance et les coûts sont très faibles. Nous avons aussi construit directement nos outils internes sur Forgejo
      Comme l’hébergement est on-premise, le développement et la CI ne s’arrêtent pas même si Internet tombe. Il prend aussi en charge le cache du gestionnaire de paquets, ce qui facilite la gestion des dépendances
    • En termes de facilité de maintenance, gitea est de loin supérieur. Je l’utilise depuis plus de 5 ans, et une mise à niveau se résume à pull la nouvelle version puis redémarrer le daemon
      Il y a eu 10 fois moins d’indisponibilité que sur GitHub, et la plupart des interruptions étaient en plus planifiées
      Quand je vois des messages qui affirment que la disponibilité de GitHub est meilleure, ça me fait rire
    • Pour un projet personnel, je pense qu’un simple serveur SSH et le système de fichiers suffisent largement
      Quand je crée un nouveau dépôt, un git init --bare suffit, et les sauvegardes tournent aussi automatiquement
      Si on développe seul, je trouve qu’une UI n’est pas vraiment nécessaire
    • D’après la documentation sur les concepts de base de Forgejo Actions, le système de CI est bien organisé
      Je pense que la CI à la GitLab est bien meilleure que GitHub Actions ; GitHub est devenu le standard grâce à sa popularité, mais sa conception laisse à désirer
    • Si vous voulez une alternative plus minimaliste, il y a aussi Gerrit. C’est une application Java sans dépendance à une base de données externe, qui stocke la configuration et les informations d’exécution dans un dépôt git
      Avec un simple système de fichiers partagé, l’extension et les sauvegardes restent simples

  • J’anime un club de mathématiques dans ma région, et les enfants utilisent Forgejo pour rendre leurs devoirs en LaTeX et Python
    Comme la gestion des connexions et la réinitialisation des mots de passe sont simples, c’est aussi très utile dans un cadre éducatif

  • Je comprends l’avis de ceux qui n’aiment pas le modèle de notifications push de GitHub et préfèrent ne voir les mises à jour que lorsqu’ils vont les vérifier eux-mêmes
    En utilisant des filtres e-mail, on peut transformer les notifications push en modèle pull. Il suffit de regrouper les notifications dans un dossier dédié et de ne les consulter qu’au moment voulu

    • Si ça ne suffit toujours pas, il suffit d’utiliser la fonction de notifications intégrée à l’UI de GitHub. Honnêtement, ça donne presque l’impression de créer un problème pour le simple plaisir d’en chercher un

  • Le témoignage de quelqu’un qui a créé lui-même buggy, un simple bug tracker, est intéressant. Apparemment, c’est un outil en C qui parse du Markdown pour générer des pages HTML
    L’esprit hacker est bien vivant

    • Mais je pense que presque personne n’adoptera une telle approche. À ma place, j’aurais plutôt l’impression de me créer encore plus de problèmes
    • C’est une approche qui a à la fois des avantages et des inconvénients

  • Quelqu’un a demandé la différence entre le modèle push et le modèle pull

    • Cela semble désigner des workflows basés sur l’e-mail, comme sur Source Hut ou dans le noyau Linux. On peut récupérer les patchs en local via IMAP et travailler hors ligne
    • Le push impose une pression du type « fais-le tout de suite », tandis que le pull relève d’une différence dans la gestion du temps, où l’on vérifie selon le rythme qu’on a soi-même défini

  • Je pense qu’on est actuellement dans une phase de dispersion où les alternatives à GitHub se multiplient
    Il est possible que, dans quelques mois, une solution dominante finisse par émerger. Si une entreprise connue ou une personnalité reconnue lance une nouvelle plateforme, elle pourrait aussi prendre le contrôle du marché

    • Cette dynamique existe depuis déjà 10 ans. À l’époque, on passait plutôt à GitLab, et même aujourd’hui, la discoverability de GitHub reste sans équivalent
      Les projets qui quittent GitHub restent extrêmement rares, donc je pense qu’il est encore trop tôt pour tirer des conclusions
    • Comme chaque développeur a sa propre manière de collaborer, il est difficile d’imaginer une convergence vers une solution unique
      Au contraire, on assiste à une re-décentralisation. C’est une époque où chacun choisit la forge qui correspond à son niveau de contrôle, à sa juridiction et à son workflow
    • À l’avenir, l’objectif est d’aller vers une structure fédérée plutôt que centralisée comme GitHub. On ne dépendrait plus d’une seule entité
    • La vraie question, c’est de savoir si l’on veut « un remplaçant unique », ou si l’on préfère revivre exactement la même situation dans 5 ans
    • C’est précisément ce que nous essayons de faire. Nous préparons Tangled, une plateforme de collaboration centrée sur les indépendants, et une annonce importante arrive bientôt

  • J’aimerais inviter le projet Dillo sur Tangled → tangled.org

    • Le fait que ça fonctionne très bien sans JavaScript est impressionnant
    • J’aimerais aussi qu’il y ait un support pour des systèmes de gestion de versions autres que Git

  • Je pense que le plus gros problème de GitHub, c’est que l’expérience d’utilisation est devenue plus lente

    • Je me demande si l’expression « more and more slow » est naturelle. « slower and slower » est-elle plus courante ?
    • Avant, ça allait, mais récemment le chargement des pages est devenu beaucoup trop lent. Ce n’est probablement pas uniquement à cause de React
      Pour explorer le code, j’utilise github.dev, mais les PR et Actions restent lents et pénibles

  • Si vous voulez installer Forgejo sur une VM, j’ai préparé un script qui permet de configurer le serveur et le runner d’un coup → easyforgejo

  • Je n’ai pas d’expertise particulière sur ce sujet, mais j’ai trouvé ça intéressant à lire
    Je suis surpris de voir à quel point il y a autant d’éléments à prendre en compte pour mettre en place un système de gestion de versions
    J’utilise Fossil, et c’est bien plus simple quand, dans une petite organisation, une seule personne doit cumuler les rôles de développeur, d’administrateur système et de support
    Les limitations des deploy keys de GitHub sont aussi pénibles. Quand on gère plusieurs applications et serveurs, devoir configurer une clé séparée pour chacun devient fastidieux