从GitHub迁移Dillo
Migrating Dillo from GitHub

原始链接: https://dillo-browser.org/news/migration-from-github/

## Dillo 项目迁移总结 出于对 GitHub 资源需求日益增加、JavaScript 依赖(与 Dillo 本身不兼容)以及潜在的单点故障数据丢失的担忧,Rodrigo Arias Mallo 正在将 Dillo 项目迁移到自托管基础设施。 原始 Dillo 网站在 2022 年丢失,凸显了依赖单一实体的风险。 新的设置包括一个自托管服务器 (dillo-browser.org),并在 Codeberg 和 Sourcehut 上镜像 git 仓库以实现冗余。 使用轻量级、无 JavaScript 的 git 前端 (cgit) 来访问代码。 一个自定义的简单缺陷跟踪器 (“buggy”) 使用纯 Markdown 文件,避免了数据库依赖并支持离线工作。 邮件列表存档由独立服务维护。 虽然 GitHub 仓库将在过渡期间保留为存档,但目标是完全独立。 该项目利用 OpenPGP 签名进行验证,增强了对 DNS 故障的抵御能力。 迁移正在进行中,该项目依赖通过 Liberapay 提供的捐赠来支付持续的托管成本,预计可持续至少三年。 此举优先考虑“拉”模式的更新,并旨在避免助长对开放网络有害的趋势。

## Dillo 浏览器迁移自 GitHub 及更广泛的讨论 Dillo 浏览器项目正在迁移离开 GitHub,引发了关于替代方案以及该平台主导地位的讨论。此举凸显了对 GitHub 前端的 frustations,特别是其日益依赖 JavaScript,这破坏了可访问性,并降低了那些禁用 JavaScript 的用户的体验。 评论员指出,更广泛的“离散”项目正在离开 GitHub,转向各种替代方案,但质疑是否会出现一个单一的主导平台,或者一个联邦解决方案会获得发展。虽然许多项目正在探索 GitLab 等选项,但 GitHub 仍然是发现项目的首要平台。 一个关键点是 GitHub 似乎优先考虑对股东有吸引力的功能(如 AI 集成),而不是解决用户报告的可访问性问题。这场对话反映了对平台控制日益增长的担忧,以及对开放、可访问的 Web 开发重要性的认识。
相关文章

原文
Written on 2025-11-30 by Rodrigo Arias Mallo

I would like to migrate the Dillo project away from GitHub into a new home which is more friendly to be used with Dillo and solves some of its problems. This page summarizes the current situation with GitHub and why I decided to move away from it into a self-hosted server with multiple mirrors in other forges.

Background

Before we dive into the details, I would like to briefly mention what happened with the old site. The original Dillo website was at dillo.org, which also had the source code of Dillo in a mercurial repository at hg.dillo.org. But it also included the mail server used to reach the developers, a bug tracker and archives for the mailing list. However, in 2022 the domain was lost and someone else decided to buy it to put a similar site but plaged with AI generated ads. The original developers are no longer active, but luckily I had a copy of the mercurial repository and with some help I was able to recover a lot of material from the original server (some parts are still missing to this day).

I want to avoid this situation as much as possible, so we cannot rely on a single site that can go down and the whole project become lost. Initially, I uploaded the Dillo source and website to git repositories on GitHub, but I no longer think this is a good idea.

The situation with GitHub

GitHub has been useful to store all repositories of the Dillo project, as well as to run the CI workflows for platforms in which I don't have a machine available (like Windows, Mac OS or some BSDs).

However, it has several problems that make it less suitable to develop Dillo anymore. The most annoying problem is that the frontend barely works without JavaScript, so we cannot open issues, pull requests, source code or CI logs in Dillo itself, despite them being mostly plain HTML, which I don't think is acceptable. In the past, it used to gracefully degrade without enforcing JavaScript, but now it doesn't. Additionally, the page is very resource hungry, which I don't think is needed to render mostly static text.

Another big problem is that it is a single point of failure. I don't mean that GitHub is stored in a single machine, but it is controlled by a single entity which can unilateraly ban our repository or account and we would lose the ability to notify in that URL what happened. This can cause data loss if we don't have a local copy of all the data.

On the usability side, the platform has become more and more slow over time, which is affecting the development process. It also requires you to have a fast Internet connection at all times, which is not the case for me sometimes. Additionally, GitHub seems to encourage a "push model" in which you are notified when a new event occurs in your project(s), but I don't want to work with that model. Instead, I prefer it to work as a "pull model", so I only get updates when I specifically look for them. This model would also allow me to easily work offline. Unfortunately, I see that the same push model has been copied to alternative forges.

On the social side, I feel that it doesn't have the right tools to moderate users, specially for projects where the ratio of non-technical users to developers is high. This is specially problematic when active issues with developer notes begin to be filled with comments from users that have never contributed to the project and usually do more harm than good. This situation ends up causing burnout in developers.

Lastly, GitHub seem to follow the current trend of over-focusing on LLMs and generative AI, which are destroying the open web (or what remains of it) among other problems. It has a direct impact on us because sites protect themseves with a JavaScript wall (or worse, browser fingerprinting) to prevent aggresive LLM crawler bots from overloading the site, but they also leave Dillo users out. So I would prefer not to encourage this trend. Despite my intentions, moving Dillo away won't change much their capability to train their model with our code, but at least I won't be actively helping.

Self-hosting Dillo

After researching the available options, it seems that none of the current forges would allow us to have a redundant system that can prevent the forge from becoming a single point of failure and solve the rest of the problems with GitHub. Therefore, I decided to self-host Dillo myself, move all important data to git repositories and keep them synchronized in multiple git mirrors.

I decided to buy the dillo-browser.org domain name and setup a very small VPS. Initially, I was very skeptical that it would be able to survive on today's web, but it seems to be doing an acceptable job at handling it (mostly AI bot traffic masquerading as users). The Dillo website is available here:

https://dillo-browser.org/

I researched which git frontends may suit our needs, and I discovered that most options are very complicated to self-host and require a lot of server resources and JavaScript on the frontend. I ended up testing cgit, which is written in C and it seems to be very lightweight both on RAM and CPU usage. Furthermore, the web frontend doesn't require JS, so I can use it from Dillo (I modified cgit CSS slightly to work well on Dillo). It is available on this URL:

https://git.dillo-browser.org/

Regarding the bug tracker, I also took a look at the available options. They are all too complicated for what I would like to have and they seem to centralize the data into a database that can get lost. This is precisely the case that happened with the old dillo bug tracker and we are still unable to recover the original bug entries.

To avoid this problem, I created my own bug tracker software, buggy, which is a very simple C tool that parses plain Markdown files and creates a single HTML page for each bug. All bugs are stored in a git repository and a git hook regenerates the bug pages and the index on each new commit. As it is simply plain text, I can edit the bugs locally and only push them to the remote when I have Internet back, so it works nice offline. Also, as the output is just an static HTML site, I don't need to worry about having any vulnerabilities in my code, as it will only run at build time. You can see it live here, with the exported issues from GitHub:

https://bug.dillo-browser.org/

The mailing list archives are stored by three independent external services, but I might include a copy with our own archives in the future.

Setting up mirrors

As all the important data is now stored in git repositories, we can mirror them in any forge, without having to rely on their custom storage format for the issues or other data. If a forge goes down (or goes rogue) we can simply switch to another site with low switching cost. To this end, I have created git mirrors in Codeberg and Sourcehut that are synced with our git server:

However, we still have a single point of failure: the DNS entry of the dillo-browser.org domain. If we lose the DNS entry (like with dillo.org) it would cause a problem as all services will be unreachable. We could recover from such situation by relying on alternative ways to reach users, by the mailing list, fediverse or IRC, as well as updating the mirrors to reflect the current situation. It is not ideal, but I don't think it would cause a catastrophic data loss (like it happened before) as all the data is now stored in git and replicated across independent locations.

OpenPGP signature

In order for this page to have some authority, the HTML file is signed with my GPG key (32E65EC501A1B6FDF8190D293EE6BA977EB2A253), which is the same that I use to sign the last releases of Dillo and is also listed in my GitHub user. The signature is available here and is linked to the page with the <link> tag using the rel=signature relation. You can find more information and how to verify the signature in the Dillo RFC-006.

Using OpenPGP signatures is robust against losing the DNS entry, as the authority is not given by the TLS certificate chain but by the trust in the OpenPGP signature, so we could move the site elsewhere and still claim that is owned by us. Additionally, as we can store the signatures inside all git mirrors, they are also resilient against data loss.

Closing remarks

Keep in mind that the migration process requires several moving parts and it will take a while for it to stabilize (switching costs). The GitHub repositories won't be removed at any point in time and they will continue to be updated until we finish the migration. When the migration process is completed, I will mark the Dillo repositories as archived and properly comunicate it in our site. It is important that we don't remove any commit or tarball release to avoid breaking downstream builds that still rely on the GitHub URL.

Lastly, I'm glad that we can have our own fully independent and self-hosted site with relatively low expenses and very little energy cost (which is good for the environment, but probably not even noticeable at large scale). With the current DNS and server costs and our current donations I consider that it is likely that we can continue covering the expenses for at least the next 3 years in the worst case scenario. If you are interested in keeping us afloat, you can help via Liberapay.

联系我们 contact @ memedata.com