Der neue Indexer von Tangled läuft inzwischen verteilt über elf Regionen. Vorher stand die ganze Anwendung auf einem einzigen, mittelgroßen Server in Schweden. Wer weiter als 50 bis 100 Millisekunden entfernt saß, merkte das bei jedem Klick. Tangled will die Code-Forge neu denken: Code dort hosten, wo man ihn haben will, und trotzdem mit allen anderen zusammenarbeiten. Auf den ersten Blick ein Widerspruch – entweder liegt der Code bei mir, oder wir arbeiten gemeinsam daran.
Eine gemietete Werkstatt ist ein guter Vergleich: Räume und Werkzeug bequem gestellt bekommen, aber Schlüssel und Öffnungszeiten aus der Hand geben. Dieses Modell gerät in Bewegung. Der folgende Text schaut sich an, wie Tangled das löst, welche Architektur dahintersteht und wo man genauer hinschauen sollte.
Warum die zentrale Code-Forge an Bedeutung verliert
Zwei Jahrzehnte lang war die Forge der Ort, an dem ein Projekt lebte: Der Code liegt dort, Änderungen werden dort besprochen, Beitragende finden sich dort. Der Preis für diese Bequemlichkeit war immer die Zentralisierung. Die Ankündigung des Projekts benennt das offen: Verfügbarkeit, Funktionsumfang und pfleglicher Umgang mit dem eigenen Code in fremde Hände zu legen, habe sich nicht ausgezahlt. Ob das stimmt, ist nicht gemessen – aber viele Teams haben diese Erfahrung schon gemacht.
Was die Zeit überdauert hat, ist unspektakulär. Git bewegt den Code, E-Mail bewegt das Gespräch darüber. Beides funktioniert seit Jahrzehnten, weil es offene Protokolle sind und niemand sie zentral abschalten kann. Der Haken war immer die Oberfläche. Wer einmal in einem ordentlich gebauten Review-Workflow gearbeitet hat, will nicht zurück zu handgeschriebenen Patch-Mails. Genau hier setzt Tangled an: die Langlebigkeit eines offenen Protokolls plus den Schliff einer richtigen Forge.
Das Team nennt sein Projekt die erste wirklich föderierte Code-Forge. Solche Selbstbeschreibungen sagen wenig. Interessanter ist die Frage, wieweit die Föderation technisch trägt – ob ein Repository auf dem eigenen Server tatsächlich gleichberechtigt neben einem auf einem fremden Server steht.
Knoten, Indexer, Frontend: der Aufbau der föderierten Code-Forge
Die Grundlage ist das AT Protocol, jenes offene Protokoll, das ursprünglich für das soziale Netzwerk Bluesky entwickelt wurde und inzwischen als allgemeine Basis für dezentrale Anwendungen dient. Jede Identität hat dort eine DID, eine kryptografisch ableitbare Kennung, und einen Handle als lesbaren Namen. Die eigenen Datensätze liegen auf einem PDS, einem Personal Data Server, den man selbst betreiben oder bei einem Anbieter mieten kann.
Auf dieser Basis gibt es bei Tangled mehrere Diensttypen. Der Knot ist der eigentliche Git-Server. In der zweiten Ausbaustufe, Knot2 genannt, wurde er in Rust neu geschrieben und bringt einen eigenen Git-Server samt SSH-Unterstützung im selben Binary mit. Dazu kommt bobbin, ein zustandsloser Indexer in Rust, der nur im Arbeitsspeicher läuft. Er ist rein lesend und befasst sich nur mit AT-Protocol-Daten; dafür läuft er in über elf Regionen, damit API und Oberfläche weltweit schnell antworten.
Vorher war all das ein einziger Go-Monolith namens Appview auf einem einzelnen Server mit SQLite-Datenbank. Er erledigte Indexierung, Caching, nicht-protokollierte Daten und das Rendering per html/template und htmx. Das Frontend ist inzwischen eine eigenständige Svelte-Anwendung am Netzrand. Die restlichen Aufgaben liegen bei einer Reihe unterstützender Dienste, deren kleinster sich als ultraleichter API-Server beschreiben lässt.
Der Sinn dieser Aufteilung ist Ersetzbarkeit. Das Team verweist auf einen Knot, der auf Cloudflare Workers läuft und deren Artifacts-Produkt als Git-Speicher nutzt, sowie auf einen vollständig eigenen Dienst des Typs Spindle. Man kann einzelne Teile tauschen, ohne das Ganze zu verlieren.
Issues und Pull Requests ziehen zum Code
Die zweite Neuerung betrifft das Datenmodell: Alles liegt jetzt unter org.tangled., die alten sh.tangled.-Datensätze sind abgelöst. Der inhaltlich spannendere Teil ist, wohin Issues, Pull Requests, Kommentare, Reaktionen und Labels gewandert sind. Sie liegen nun direkt auf dem Knot, neben dem Code, als Collaborative Objects, kurz COBs. Ein COB ist nichts Exotisches: eine Kette von Git-Objekten im Repository selbst. Auch Mitarbeitende, Knot-Mitglieder und die Blockliste werden so gespeichert.
Damit funktioniert ein Knot ähnlich wie ein PDS. Er hält signierte Datensätze inklusive vollständiger Historie für alles, was zu einem Repository gehört, und synchronisiert sie über den standardisierten Firehose – den Datenstrom, in dem Änderungen als signierte Ereignisse durchs Netz laufen. Das Argument dahinter: Die Issues eines Projekts gehören genauso dazu wie der Code, also sollten sie mit ihm zusammen liegen, egal wo es gehostet wird. Für die Portabilität ist das ein Vorteil.
Eine Sorge liegt nahe: Wenn der Knot meine Issues schreibt, was hindert ihn daran, mir Worte in den Mund zu legen? Die Antwort sind Attestierungen. Jedes Mal, wenn man einen Datensatz auf einem Knot anlegt oder ändert, schreibt die Web-App zusätzlich einen org.tangled.graph.attestation-Eintrag in das eigene PDS – mit Verweis auf genau diese Version des Datensatzes und die zugrunde liegende COB-Änderung. Geprüft wird in beide Richtungen. Wer selbst hostet, muss den Knot nach Anleitung auf Version 1.20.0 heben.
Organisationen, gestapelte Pull Requests und eine aufgefrischte Oberfläche
Neu sind auch echte Organisationen. Ein Organisationskonto ist ein reguläres AT-Protocol-Konto mit eigener DID und eigenem Handle, gehostet auf einer Tranquil-PDS-Instanz. Es ist passwortlos und delegiert: Man legt es über die Seite für neue Organisationen an und erhält <name>.tngl.sh, wobei man selbst als Eigentümer eingetragen ist. Wer einlädt, kann Mitglieder hinzufügen, und jedes Mitglied kann im Namen der Organisation handeln, etwa Repositories anlegen oder forken. Das Handle lässt sich gegen eine eigene Domain tauschen; für alle, die bisher ein normales Konto als Notlösung genutzt haben, ist eine Migration angekündigt, aber noch nicht fertig.
Der Review-Workflow wurde ebenfalls überarbeitet. Gestapelte Pull Requests, also mehrere aufeinander aufbauende Änderungssätze, sind jetzt für alle zugänglich – egal ob mit Jujutsu oder mit gewöhnlichem Git gearbeitet wird. Git-Nutzende bekommen einen Interdiff zwischen Versionen, der zeigt, was sich seit der letzten Runde geändert hat. Bei Jujutsu geht das bis auf einzelne Changes herunter.
Dazu kommt eine neue Oberfläche, in Svelte neu gebaut, mit anderer Schrift. Sie soll schneller und konsistenter sein. Weitere Teile folgen gestaffelt: private Repositories, ein CLI, SDKs für verschiedene Sprachen und Fähigkeiten für Agenten. Eine Ankündigung mit Zeithorizont, keine fertige Liste.
Eigene Infrastruktur für Code-Hosting: was Selbst-Hosting hier heißt
Der pragmatische Kern ist die Wahlfreiheit beim Ausbau. Man kann nur Teile selbst betreiben, etwa das Git-Hosting oder die CI-Runner, oder alles inklusive API-Server und Oberfläche – und trotzdem mit allen anderen sprechen, die woanders hosten. Wer die eigene Infrastruktur stellt, darf außerdem am eigenen Werkzeug basteln, es erweitern und anpassen, statt auf die Roadmap eines Anbieters zu warten.
Weil die Basis das AT Protocol ist, lassen sich eigene Erweiterungen bauen, der Firehose abonnieren oder eigene Knoten schreiben. Das Team betont, wie agentenfreundlich das Ganze sei, und liefert die Begründung gleich mit: Software, die von Anfang an auf Veränderbarkeit ausgelegt ist, lässt sich leichter von Agenten anpassen. Ob das eher Versprechen oder Prognose ist, wird sich zeigen – die Werkzeuge dafür sind vorhanden.
Klar gesagt: Föderation heißt hier AT Protocol, nicht ActivityPub. Wer aus der Fediverse-Ecke kommt, findet nicht dieselben Server vor, und die Vorstellung, einfach die eigene Instanz anzusteuern und alles läuft wie gewohnt, stimmt nicht. Die Architektur ist jung, mit Umstellungsschritten, Versionssprüngen und Baustellen wie der Organisations-Migration.
Fazit: was zu prüfen bleibt
Tangled führt eine saubere Trennung von Daten und Darstellung vor. Der Indexer ist zustandslos, die Knoten halten die Inhalte, die Attestierungen liegen bei den Nutzenden, das Frontend ist austauschbar. Diese Aufteilung ist der eigentliche Gewinn – mehr als die neue Oberfläche oder die gestapelten Pull Requests.
Wer eine dezentrale Code-Verwaltung mit AT Protocol ausprobieren will, findet hier den derzeit vollständigsten Entwurf. Für einen produktiven Umzug sollte man die Reife abwarten und sich die Upgrade-Pfade genau ansehen. Wer einfach nur in Ruhe Open-Source-Projektmanagement mit Pull Requests betreiben will, hat mit dem zentralen Modell weiterhin weniger Arbeit. Am Ende ist die Entscheidung keine technische, sondern eine über Abhängigkeiten: Wie viel Kontrolle will man selbst tragen, und wie viel Bequemlichkeit gibt man dafür auf.
Quelle: tangled.org
