Migración del proyecto Dillo desde GitHub

 (dillo-browser.org)
2 puntos por GN⁺ 2025-12-01 | 1 comentarios | Compartir por WhatsApp
  • El navegador web el proyecto Dillo está migrándose desde GitHub a un servidor autohospedado
  • La dependencia de JavaScript, la estructura de control único y el bajo rendimiento de GitHub se citaron como las principales razones para la migración
  • El nuevo servidor opera en el dominio dillo-browser.org, usando un frontend Git ligero basado en cgit y un rastreador de errores propio llamado ‘buggy’
  • Todos los datos se gestionan como repositorios Git y se replican en Codeberg y Sourcehut, lo que minimiza el riesgo de pérdida de datos
  • Se diseñó para mantener la confianza incluso en caso de pérdida de DNS mediante firmas OpenPGP, reforzando la independencia y continuidad del proyecto

Antecedentes

  • El sitio original de Dillo era dillo.org y contenía un repositorio Mercurial, servidor de correo, rastreador de errores y archivo de la lista de correo
    • En 2022 se perdió el dominio y un tercero creó un sitio similar lleno de anuncios de IA
    • Parte del material se recuperó, pero no por completo
  • Por esa experiencia se decidió evitar depender de un único sitio y construir una estructura de respaldo distribuida
  • Al principio se subió el código a GitHub, pero luego se consideró que no era adecuado a largo plazo

Problemas de GitHub

  • GitHub resultó útil para los flujos de CI y la gestión de repositorios, pero tiene varias limitaciones
    • El frontend no funciona sin JavaScript, por lo que no se pueden ver issues ni PR con el navegador Dillo
    • Las páginas consumen demasiados recursos y generan carga innecesaria solo para renderizar HTML simple
  • Existe riesgo de que, por un único actor con control central, se bloquee la cuenta y se corte el acceso a los datos
  • La plataforma se vuelve cada vez más lenta y exige una conexión de internet rápida
  • El esquema de notificaciones de “push” de GitHub no se ajusta a un desarrollo con enfoque offline
  • La falta de herramientas de gestión comunitaria en proyectos con alta proporción de usuarios no desarrolladores incrementa la fatiga de los mantenedores
  • Al migrar GitHub hacia LLM y AI generativa, los sitios endurecieron defensas para bloquear crawlers de LLM con muros de JavaScript o huella del navegador, entre otros
    • Esto provocó efectos secundarios donde se bloqueaba el acceso de usuarios de Dillo

Configuración en servidor propio

  • Los servicios de repositorio existentes no lograban satisfacer al mismo tiempo la eliminación de un único punto de fallo y la operación ligera
    • Por eso se decidió operar un servidor propio y mantener múltiples mirrors
  • Compraron el dominio dillo-browser.org y montaron un VPS pequeño
    • Está funcionando de forma más estable de lo esperado y maneja principalmente tráfico de bots de IA
  • Eligieron cgit como frontend Git
    • Está escrito en C, usa menos RAM y CPU, y funciona sin JavaScript
    • Ajustaron algo de CSS para que se muestre bien en Dillo
    • Disponible en https://git.dillo-browser.org/
  • El bug tracker que usan es ‘buggy’, desarrollado internamente
    • Convierte archivos Markdown a páginas HTML; cada bug se guarda en un repositorio Git
    • Al hacer commit, un hook de Git actualiza automáticamente las páginas
    • Permite edición offline y no hay preocupaciones de vulnerabilidades de seguridad
    • Visible en https://bug.dillo-browser.org/
  • El archivo de la lista de correo está distribuido en 3 servicios externos, y se planea añadir una copia propia en el futuro

Configuración de mirrors

  • Todos los datos críticos se gestionan como repositorios Git y se replican en Codeberg y Sourcehut
    • Si un repositorio deja de funcionar, es posible migrar a otro mirror con bajo costo de conmutación
  • El único punto único de fallo es DNS (dillo-browser.org)
    • Si se pierde DNS, se puede notificar a los usuarios por lista de correo, Fediverse, IRC, etc.
    • Los datos están replicados en Git, por lo que no se producirá una pérdida crítica

Firmas OpenPGP

  • Esta página está firmada con la clave GPG de Rodrigo Arias Mallo (32E65EC501A1B6FDF8190D293EE6BA977EB2A253)
    • Es la misma clave que se usa en el último release de Dillo y también está registrada en la cuenta de GitHub
    • El archivo de firma (index.html.asc) está vinculado con <link rel=signature>
  • Las firmas OpenPGP permiten mantener la confianza incluso ante pérdida de DNS
    • En lugar de una cadena de certificados TLS, se prueba la propiedad mediante confianza basada en firmas
    • La firma se incluye en todos los mirrors Git para reforzar la tolerancia a pérdida de datos

Progreso y perspectivas de la migración

  • El repositorio de GitHub no se eliminará de inmediato y seguirá recibiéndose actualizaciones hasta terminar la migración
    • Tras completarla, el repositorio se moverá al estado de “archived” y se anunciará en el sitio oficial
    • Los commits y archivos de release existentes se mantienen para conservar la compatibilidad hacia atrás
  • La nueva infraestructura permite operar de forma independiente con bajo costo y bajo consumo de energía
    • Según las donaciones actuales y el costo del servidor, puede sostenerse por al menos 3 años
    • Si quieres apoyar, puedes hacerlo a través de Liberapay (https://liberapay.com/dillo/)

Lecturas relacionadas

1 comentarios

 
GN⁺ 2025-12-01
Comentario de Hacker News

  • Durante años he usado GitLab como alternativa self-hosted. Me gusta, pero consume muchísimos recursos
    Últimamente estoy probando Forgejo, hecho por el equipo de Codeberg, y la verdad es que está excelente
    La mayor diferencia es el uso de memoria. GitLab está basado en Ruby on Rails, así que corren varios servicios al mismo tiempo, mientras que Forgejo tiene una estructura de binario único escrita en Go
    GitLab termina consumiendo poco a poco toda la memoria de una VM de 16 GB, pero Forgejo usa apenas unos 300 MB incluso corriendo juntos el servidor y el runner
    No tiene GraphQL, pero su API REST parece más que suficiente
    No tengo muy clara la diferencia entre gitea y forgejo, pero al ver la documentación comparativa de Forgejo, parece que fue un soft fork en 2022 por temas de gobernanza

    • En nuestro estudio, unas 50 personas usan git todos los días, y hace 2 años migramos por completo a Forgejo
      Como está basado en Go y su estructura es simple, el mantenimiento y los costos son muy bajos. También construimos herramientas internas directamente sobre Forgejo
      Como lo alojamos on-premise, aunque se caiga internet el desarrollo y el CI no se detienen. También soporta caché de package managers, así que manejar dependencias es fácil
    • En facilidad de mantenimiento, gitea gana por mucho. Llevo más de 5 años usándolo y para actualizar basta con hacer pull de la nueva versión y reiniciar el daemon
      Ha tenido 10 veces menos downtime que GitHub, y además casi todo fue mantenimiento programado
      Cuando veo publicaciones diciendo que GitHub tiene mejor disponibilidad, me da risa
    • Para proyectos personales, creo que basta con un servidor SSH y el sistema de archivos
      Al crear un repositorio nuevo, todo se resuelve con git init --bare, y los respaldos también corren automáticamente
      Si desarrollas solo, siento que realmente no hace falta una UI
    • Si ves la documentación de conceptos básicos de Forgejo Actions, el sistema de CI está muy bien organizado
      Creo que el CI estilo GitLab es mucho mejor que GitHub Actions; GitHub se volvió estándar gracias a su popularidad, pero su diseño deja que desear
    • Si quieres una alternativa más minimalista, también está Gerrit. Es una app en Java sin dependencia de una base de datos externa, y guarda la configuración y la información de runtime en un repo git
      Solo con un sistema de archivos compartido, escalar y hacer respaldos es simple

  • Dirijo un club de matemáticas en mi zona, y usamos Forgejo para que los chicos entreguen tareas de LaTeX y Python
    Como es fácil gestionar inicios de sesión y restablecer contraseñas, también resulta muy útil para educación

  • También coincido con la opinión de que no gusta el modelo push de notificaciones de GitHub y que uno preferiría ver actualizaciones solo cuando decide revisarlas
    Usando filtros de correo, puedes convertir las notificaciones push en algo parecido a un modelo pull. Solo juntas las notificaciones en una carpeta dedicada y las ves cuando quieras

    • Aun así, si eso no te satisface, puedes usar la función de notificaciones dentro de la propia UI de GitHub. La verdad, se siente como buscarle problema a algo por buscarle problema

  • Me pareció interesante la historia de alguien que creó por su cuenta el bug tracker simple “buggy”. Dice que es una herramienta en C que parsea Markdown y genera páginas HTML
    Ese espíritu hacker sigue vivo

    • Pero creo que casi nadie tomaría ese enfoque. Yo más bien siento que me traería todavía más problemas
    • Es un enfoque que tiene tanto ventajas como desventajas

  • Hubo una pregunta sobre la diferencia entre “modelo push” y “modelo pull”

    • Creo que se refiere a un workflow basado en correo electrónico como Source Hut o el kernel de Linux. Puedes traer los parches en local con IMAP y trabajar incluso sin conexión
    • El push trae esa presión de tiempo de “hazlo ahora mismo”, mientras que el pull es una diferencia en la forma de gestionar el tiempo, porque revisas las cosas según el ritmo que tú defines

  • Creo que ahora estamos en una fase de dispersión (diáspora) en la que están brotando varias alternativas a GitHub
    Puede que en unos meses una opción principal termine consolidándose. Si una empresa o persona conocida lanza una plataforma nueva, también podría liderar el mercado

    • Esta tendencia existe desde hace 10 años. Antes hubo una época en la que la gente se cambiaba a GitLab, y aun hoy la discoverability de GitHub sigue siendo incomparable
      Son muy pocos los proyectos que abandonan GitHub, así que creo que todavía es muy pronto
    • Como cada desarrollador colabora de manera distinta, es difícil que todo converja en una sola solución
      Más bien está ocurriendo una re-descentralización. Estamos entrando en una época en la que cada quien elige el forge que mejor se ajusta a su control, su jurisdicción y su workflow
    • A futuro, el objetivo es pasar a una estructura federada en vez de una centralizada como GitHub. Así dejamos de depender de una sola entidad
    • Lo importante es si quieres “un único reemplazo”, o si prefieres repetir esta misma situación otra vez dentro de 5 años
    • Nosotros justamente estamos intentando eso. Estamos preparando una plataforma de colaboración centrada en indies llamada Tangled, y pronto habrá un anuncio grande

  • Me gustaría invitar al proyecto Dillo a Tangled → tangled.org

    • Impresiona que funcione bien incluso sin JavaScript
    • Ojalá también soportara sistemas de control de versiones aparte de Git

  • Creo que el mayor problema de GitHub es su usabilidad cada vez más lenta

    • Me pregunto si la expresión “more and more slow” suena natural. ¿“slower and slower” sería más común?
    • Antes estaba bien, pero últimamente la carga de páginas es demasiado lenta. No parece ser solo por React
      Para explorar código uso github.dev, pero los PR y Actions siguen siendo lentos y frustrantes

  • Si quieres instalar Forgejo en una VM, hice un script con el que puedes configurar de una vez el servidor y el runner → easyforgejo

  • No soy experto en este tema, pero me pareció una lectura interesante
    Me sorprende que haya tantos factores involucrados en montar un sistema de control de versiones
    Yo uso Fossil, y para organizaciones pequeñas es mucho más simple cuando una sola persona hace de desarrollador, administrador de sistemas y soporte
    Las limitaciones de deploy keys de GitHub también son incómodas. Cuando manejas varias apps y servidores, es molesto tener que configurar cada clave por separado