Bots, Proof-of-Work und die Kunst desdo-the-work

Die Realität ist: Unser Netz wird von Bots überflutet. Crawler, Scraper, automatisierte Skripte – sie bombardieren Webseiten pausenlos mit Anfragen. Git-Hoster bleiben davon nicht verschont. Die übliche Reaktion: Proof-of-Work-Systeme wie Anubis einsetzen. Funktioniert ja auch – irgendwie. Aber es ist eine hässliche Lösung, die alle ausbremst.

Warum Proof-of-Work der falsche Weg ist

Proof-of-Work zwingt Browser, erst Rechenrätsel zu lösen, bevor sie auf Inhalte zugreifen dürfen. Genau das gleiche energiefressende Konzept, für das Bitcoin und Ethereum zurecht kritisiert werden. Rechenarbeit, die im nächsten Moment im Müll landet. Für Entwickler, die einfach nur Code durchsuchen wollen, fühlt sich das an wie Bestrafung dafür, dass man ein Mensch ist.

Wir haben Jahrzehnte damit verbracht, Web-Performance zu optimieren. Jede Millisekunde zählt. Verbindungzeiten werden auf theoretische Grenzen gedrückt. Und dann führen wir künstlich Verzögerungen ein, nur weil Bots nerven? Das ist ein Schlag ins Gesicht für all die Optimierungsarbeit.

Die Idee:do-the-work umdrehen

Hier kommt "do-the-work" ins Spiel. Das Konzept dreht die klassische Client-Server-Beziehung elegant um. Normalerweise schuftet der Server, während der Client faul herumsitzt. Bei do-the-work zahlt der Client die Rechenkosten für den Informationszugang.

Das klingt verrückt, ist es aber nicht – besonders bei Git-Repositories. Git speichert alles als Objekte: Commits, Trees, Blobs, Tags. Jedes Detail in einem Git-Viewer ist nur eine Berechnung von diesen Grundbausteinen entfernt. Wer die Objekte hat, hat alles.

Client-Side Git Viewer: Ein Paradigmenwechsel

Das Geniale daran: Moderne Browser können diese Arbeit locker leisten. Ein Entwickler namens legoktm hat einen komplett clientseitigen Git-Repository-Viewer gebaut, der vollständig im Browser läuft. Der Server? Der liefert nur statische Dateien – Bare-Repositories über HTTP. Keine CGI-Skripte, keine Datenbank, kein kompliziertes Backend. Nur Apache mit ein paar Rewrite-Regeln.

Der Browser lädt Objekte bei Bedarf herunter, speichert sie in IndexedDB und berechnet Diffs, Dateiinhalte und Commit-Logs lokal. Im Grunde macht er einen partiellen git clone on-demand, füllt fehlende Objekte nach, während man durch den Code navigiert. Die Aufgabe des Servers wird lächerlich einfach – nur Dateien ausliefern.

Vorteile für Entwickler und Startups

Wer ein Startup leitet oder ein kleines Dev-Team managt, sollte dieses Konzept kennen:

Bandbreite wird zur einzigen echten Baustelle. Weil nur statische Inhalte ausgeliefert werden, kann man bedenkenlos einen CDN davorschalten. Der Repository-Viewer wird praktisch unendlich skalierbar – bei minimaler Backend-Komplexität.

Datenschutz verbessert sich nebenbei. Sobald der Browser Objekte gecacht hat, brauchen Folgebesuche nichts mehr zu laden, wenn sich nichts geändert hat. Theoretisch kann man ein Repository nach dem ersten Laden komplett offline durchstöbern. Kein Server, der Surfgewohnheiten durch Seitenwechseln trackt.

Deployment wird lächerlich simpel. Statisches Hosting funktioniert überall. GitHub Pages, Netlify, Cloudflare Pages, oder einfach ein Object-Storage-Bucket – der Git-Viewer wird zur Infrastruktur, die sich quasi selbst verwaltet.

Die AI-Coding-Verbindung

Für die AI-Coding-Szene wird das besonders spannend. Wenn KI-gestützte Entwicklungstools weiter an Bedeutung gewinnen, entstehen mehr Code, mehr Repositories, mehr Bedarf an leichtgewichtigen Hosting-Lösungen. Systeme wie dieses zeigen eine Zukunft, in der Entwicklungs-Infrastruktur kein komplizierter Managed Service sein muss – sie kann einfach, statisch und überraschend leistungsfähig sein.

Die Rechenpower im Browser der Nutzer ist im Grunde kostenloses Computing, das man anzapfen kann. Statt serverseitiges Rendering zu bezahlen, erntet man clientseitige Berechnungen. Für stark frequentierte öffentliche Repositories könnte das gewaltige Kosteneinsparungen bedeuten.

Ist das die Zukunft?

Frühling ist es noch. Betrachte das als Proof-of-Concept, das Möglichkeiten aufzeigt – nicht als produktionsreife Lösung für jedermann. Aber die Grundidee stimmt: Lass den Client die Arbeit machen, und der Server bleibt schlank und effizient.

Für Git-Hosting gilt: Wer nicht das volle Forge-Erlebnis braucht – Issues, Pull Requests, CI/CD – sondern nur Code durchsuchen will, könnte cgit-Installationen durch etwas viel Skalierbareres und Datenschutz-freundlicheres ersetzen.

Das nächste Mal, wenn du darüber nachdenkst, wie du deine Dienste vor Scrapern schützt, ohne legitimen Nutzern das Leben schwerzumachen: Denk an do-the-work. Browser haben ungenutzte Kapazitäten. Server haben begrenzte Ressourcen. Lass die Browser rechnen.

Manchmal ist der beste Weg, ein Skalierungsproblem zu lösen, nicht mehr Serverpower reinzuwerfen – sondern die Arbeit dorthin zu verteilen, wo die Rechenleistung bereits existiert.