Migration des Dillo-Projekts von GitHub

 (dillo-browser.org)
2 Punkte von GN⁺ 2025-12-01 | 1 Kommentare | Auf WhatsApp teilen
  • Das Webbrowserprojekt Dillo wird von GitHub auf einen eigenen, selbst gehosteten Server migriert.
  • Als Hauptgründe für den Umzug wurden bei GitHub die JavaScript-Abhängigkeit, die zentrale Kontrollstruktur und die langsame Performance genannt.
  • Der neue Server wird unter der Domain dillo-browser.org betrieben und setzt auf ein leichtgewichtiges, cgit-basiertes Git-Frontend sowie den selbst entwickelten Bugtracker „buggy“.
  • Sämtliche Daten werden als Git-Repositories verwaltet, auf Codeberg und Sourcehut gespiegelt und so das Risiko von Datenverlust minimiert.
  • Durch die OpenPGP-Signatur ist er so ausgelegt, dass die Vertrauenswürdigkeit auch bei DNS-Verlust erhalten bleibt und Unabhängigkeit und Kontinuität des Projekts gestärkt werden.

Hintergrund

  • Die ursprüngliche Website von Dillo war früher dillo.org und enthielt ein Mercurial-Repository, einen Mailserver, einen Bugtracker und ein Mailinglisten-Archiv.
    • 2022 ging die Domain verloren, und ein Dritter eröffnete eine ähnliche Website, die mit KI-Werbung überfüllt war.
    • Ein Teil der Daten wurde wiederhergestellt, jedoch nicht vollständig.
  • Aus dieser Erfahrung heraus wurde entschieden, die Abhängigkeit von einer einzelnen Website zu vermeiden und eine verteilte Backup-Struktur aufzubauen.
  • Anfangs wurde der Code auf GitHub hochgeladen, langfristig wurde dies jedoch als ungeeignet eingestuft.

Probleme mit GitHub

  • GitHub war nützlich für CI-Workflows und Repository-Management, hat aber mehrere Einschränkungen.
    • Ohne JavaScript kann das Frontend nicht funktionieren, daher lassen sich im Dillo-Browser keine Issues oder PRs öffnen.
    • Die Seite verbraucht zu viele Ressourcen und erzeugt bei einfachem HTML-Rendering unnötige Last.
  • Durch eine einzige Kontrollinstanz besteht das Risiko, dass ein Konto gesperrt wird und damit der Datenzugriff blockiert wird.
  • Die Plattform wird immer langsamer und verlangt zunehmend eine schnelle Internetverbindung.
  • GitHubs „Push-Modell“ für Benachrichtigungen passt nicht zu einer eher offline-zentrierten Entwicklungsweise.
  • Bei Projekten mit hohem Anteil an Nicht-Entwicklern fehlen Community-Management-Tools, was die Erschöpfung der Maintainer erhöht.
  • Da GitHub sich zunehmend auf LLMs und Generative AI konzentriert, verstärken Websites dort Maßnahmen gegen LLM-Crawler wie JavaScript-Wände oder Browser-Fingerprinting.
    • Dadurch kam es zu Nebenwirkungen, bei denen Dillo-Benutzern der Zugriff verwehrt wurde.

Aufbau der eigenen Infrastruktur

  • Bestehende Repository-Dienste konnten gleichzeitig den Ausfall einer einzigen Stelle verhindern und dabei schlank betrieben werden nicht erfüllen.
    • Daher wurde beschlossen, den Server selbst zu betreiben und mehrere Mirrors zu unterhalten.
  • Die Domain dillo-browser.org wurde gekauft und ein kleiner VPS-Server eingerichtet.
    • Der Betrieb läuft stabiler als erwartet; vor allem KI-Bot-Traffic wird abgewickelt.
  • Als Git-Frontend wurde cgit gewählt.
    • cgit ist in C geschrieben, nutzt wenig RAM und CPU und arbeitet ohne JavaScript.
    • Das CSS wurde leicht angepasst, damit es in Dillo gut dargestellt wird.
    • Erreichbar unter https://git.dillo-browser.org/.
  • Als Bugtracker wird ein selbst entwickelter ‚buggy‘ eingesetzt.
    • Markdown-Dateien werden geparst und HTML-Seiten erzeugt, jeder Bug wird im Git-Repository gespeichert.
    • Bei jedem Commit aktualisiert ein Git-Hook die Seiten automatisch.
    • Offline-Bearbeitung möglich, ohne Sicherheitsbedenken.
    • Verfügbar unter https://bug.dillo-browser.org/.
  • Das Mailinglisten-Archiv wird auf 3 externe Dienste verteilt, eine eigene Kopie ist für die Zukunft geplant.

Mirror-Einrichtung

  • Alle Kerndaten werden als Git-Repositories verwaltet und auf Codeberg und Sourcehut gespiegelt.
    • Wenn ein Repository abgeschaltet wird, ist ein Wechsel zu einem anderen Mirror mit niedrigen Kosten möglich.
  • Der einzige Ausfallpunkt bleibt DNS (dillo-browser.org).
    • Bei DNS-Verlust kann man Nutzer über Mailingliste, Fediverse und IRC informieren.
    • Die Daten sind in Git repliziert, daher tritt kein katastrophaler Verlust auf.

OpenPGP-Signatur

  • Diese Seite ist mit dem GPG-Schlüssel (32E65EC501A1B6FDF8190D293EE6BA977EB2A253) von Rodrigo Arias Mallo signiert.
    • Es ist derselbe Schlüssel wie in den aktuellen Dillo-Releases und ist ebenfalls im GitHub-Account hinterlegt.
    • Die Signaturdatei (index.html.asc) ist über <link rel=signature> eingebunden.
  • OpenPGP-Signaturen ermöglichen Vertrauensaufbau auch bei DNS-Verlust.
    • Anstelle einer TLS-Zertifikatskette erfolgt der Eigentumsnachweis über Signaturvertrauen.
    • Die Signatur ist in allen Git-Mirrors enthalten, was die Ausfallsicherheit gegenüber Datenverlust verbessert.

Migrationsfortschritt und Ausblick

  • Das GitHub-Repository wird nicht sofort gelöscht und wird bis zum Abschluss der Migration weiter gepflegt.
    • Danach soll das Repository in den Zustand „archived“ versetzt werden; dies wird auf der offiziellen Website angekündigt.
    • Bestehende Commits und Release-Dateien werden zur Rückwärtskompatibilität behalten.
  • Die neue Infrastruktur lässt sich mit geringen Kosten und niedrigem Energieverbrauch eigenständig betreiben.
    • Auf Basis der aktuellen Spenden und Serverkosten ist ein Betrieb von mindestens 3 Jahren möglich.
    • Wer unterstützen möchte, kann dies über Liberapay tun: https://liberapay.com/dillo/

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-12-01
Hacker-News-Kommentar

  • Ich nutze seit einigen Jahren GitLab als Self-Hosting-Alternative. Ich mag es, aber es verbraucht viele Ressourcen
    In letzter Zeit teste ich Forgejo, entwickelt vom Codeberg-Team, und es ist wirklich großartig
    Der größte Unterschied ist der Speicherverbrauch. GitLab basiert auf Ruby on Rails, daher laufen mehrere Dienste gleichzeitig, während Forgejo als einzelnes in Go geschriebenes Binary aufgebaut ist
    GitLab belegt nach und nach den gesamten Speicher einer 16-GB-VM, aber Forgejo nutzt selbst mit Server und Runner zusammen nur etwa 300 MB
    Es gibt zwar kein GraphQL, aber die REST-API scheint völlig ausreichend zu sein
    Ich kenne den Unterschied zwischen gitea und forgejo nicht genau, aber laut Forgejos Vergleichsdokumentation scheint es 2022 wegen Governance-Problemen als Soft Fork entstanden zu sein

    • Unser Studio hat rund 50 Nutzer, die täglich Git verwenden, und wir sind vor 2 Jahren vollständig auf Forgejo umgestiegen
      Dank der einfachen, Go-basierten Struktur sind Wartungsaufwand und Kosten sehr gering. Wir haben auch interne Tools direkt auf Forgejo aufgebaut
      Da wir On-Premises hosten, kommen Entwicklung und CI auch bei Internetausfällen nicht zum Stillstand. Es unterstützt außerdem Package-Manager-Caches, was die Abhängigkeitsverwaltung erleichtert
    • In Sachen Wartungsfreundlichkeit ist gitea überlegen. Ich nutze es seit über 5 Jahren, und ein Upgrade besteht einfach darin, die neue Version zu pullen und den Daemon neu zu starten
      Es hatte 10-mal weniger Downtime als GitHub, und das meiste davon war geplante Wartung
      Wenn ich Beiträge sehe, die behaupten, GitHub habe die bessere Verfügbarkeit, muss ich lachen
    • Für ein persönliches Projekt reichen meiner Meinung nach einfach ein SSH-Server und ein Dateisystem
      Ein neues Repository ist mit git init --bare erstellt, und auch die Backups laufen automatisch
      Wenn man allein entwickelt, braucht man meiner Meinung nach nicht unbedingt eine UI
    • Laut der Dokumentation zu den grundlegenden Konzepten von Forgejo Actions ist das CI-System gut durchdacht
      Ich finde CI im GitLab-Stil deutlich besser als GitHub Actions; GitHub ist dank seiner Popularität zum Standard geworden, aber das Design lässt zu wünschen übrig
    • Wer eine noch minimalistischere Alternative möchte, kann sich Gerrit ansehen. Es ist eine Java-Anwendung ohne Abhängigkeit von einer externen Datenbank und speichert Konfiguration und Laufzeitinformationen in einem Git-Repo
      Schon mit einem gemeinsam genutzten Dateisystem sind Skalierung und Backups einfach

  • Ich leite vor Ort einen Mathe-Club, und die Kinder nutzen Forgejo, um LaTeX- und Python-Aufgaben einzureichen
    Da Login-Verwaltung und Passwort-Reset einfach sind, ist es auch für Bildungszwecke sehr nützlich

  • Ich kann die Meinung nachvollziehen, dass man das Push-Benachrichtigungsmodell von GitHub nicht mag und Updates nur dann sehen möchte, wenn man selbst nachschaut
    Mit E-Mail-Filtern kann man Push-Benachrichtigungen in ein Pull-Modell verwandeln. Man sammelt die Benachrichtigungen in einem eigenen Ordner und schaut nur dann hinein, wenn es nötig ist

    • Wenn das immer noch nicht zufriedenstellend ist, kann man einfach die eingebaute Benachrichtigungsfunktion der GitHub-Oberfläche verwenden. Ehrlich gesagt wirkt das wie ein Problem, das nur um des Problems willen gesucht wird

  • Interessant fand ich die Geschichte von jemandem, der selbst den einfachen Bug-Tracker „buggy“ gebaut hat. Es soll ein C-Tool sein, das Markdown parst und HTML-Seiten erzeugt
    Der Hacker-Geist lebt

    • Aber so einen Ansatz würde wohl fast niemand wählen. Für mich persönlich würde das eher nur mehr Probleme schaffen
    • Das ist ein Ansatz mit Vor- und Nachteilen

  • Es gab die Frage nach dem Unterschied zwischen „Push-Modell“ und „Pull-Modell“

    • Gemeint ist wohl ein E-Mail-basierter Workflow wie bei Source Hut oder dem Linux-Kernel. Per IMAP kann man Patches lokal abrufen und auch offline damit arbeiten
    • Push erzeugt den Zeitdruck von „mach das jetzt sofort“, während Pull ein anderer Ansatz des Zeitmanagements ist, bei dem man in selbst festgelegten Intervallen nachschaut

  • Ich denke, wir befinden uns gerade in einer diasporaartigen Phase, in der viele GitHub-Alternativen gleichzeitig entstehen
    Vielleicht wird sich innerhalb weniger Monate ein Mainstream-Anbieter herauskristallisieren. Wenn ein bekanntes Unternehmen oder eine prominente Person eine neue Plattform startet, könnte sie den Markt anführen

    • Solche Bewegungen gibt es schon seit 10 Jahren. Früher war es die Phase des Wechsels zu GitLab, und auch heute ist GitHubs Discoverability weiterhin konkurrenzlos
      Nur sehr wenige Projekte verlassen GitHub, daher finde ich es noch zu früh
    • Da Entwickler sehr unterschiedlich zusammenarbeiten, ist es schwer, dass sich alles auf eine einzige Lösung konzentriert
      Eher erleben wir eine erneute Dezentralisierung. Es ist eine Zeit, in der jeder die Forge wählen kann, die zu Kontrolle, Zuständigkeit und Workflow passt
    • Langfristig ist das Ziel keine zentralisierte Struktur wie GitHub, sondern eher eine Föderation, damit man nicht von einer einzelnen Entität abhängig ist
    • Entscheidend ist, ob man „einen einzigen Ersatz“ will oder ob man in 5 Jahren wieder in derselben Situation landen möchte
    • Genau das versuchen wir. Wir arbeiten an Tangled, einer kollaborativen Plattform mit Indie-Fokus, und bald wird es eine große Ankündigung geben

  • Ich würde das Dillo-Projekt gern zu Tangled einladen → tangled.org

    • Beeindruckend ist, dass es auch ohne JavaScript gut funktioniert
    • Es wäre schön, wenn es auch andere Versionsverwaltungssysteme außer Git unterstützen würde

  • Das größte Problem von GitHub ist meiner Meinung nach die immer langsamere Bedienbarkeit

    • Ich frage mich, ob die Formulierung „more and more slow“ natürlich klingt. Ist „slower and slower“ gebräuchlicher?
    • Früher war es in Ordnung, aber in letzter Zeit laden die Seiten viel zu langsam. Es liegt wohl nicht nur an React
      Für die Code-Navigation nutze ich github.dev, aber PRs und Actions bleiben weiterhin langsam und frustrierend

  • Falls jemand Forgejo auf einer VM installieren möchte: Ich habe ein Skript erstellt, mit dem man Server und Runner auf einmal einrichten kann → easyforgejo

  • Ich bin auf diesem Gebiet kein Experte, habe das aber mit Interesse gelesen
    Es überrascht mich, wie viele Faktoren bei der Einrichtung eines einzigen Versionsverwaltungssystems eine Rolle spielen
    Ich nutze Fossil, und in kleinen Organisationen, in denen man allein Entwickler, Systemadministrator und Support in Personalunion ist, ist das viel einfacher
    Auch GitHubs Einschränkungen bei Deploy Keys sind unpraktisch. Wenn man mehrere Apps und Server betreibt, muss man die Schlüssel jeweils getrennt einrichten, was lästig ist