Tangled – Git-Kollaborationsplattform auf atproto-Basis

 (blog.tangled.org)
3 Punkte von GN⁺ 2025-10-12 | 2 Kommentare | Auf WhatsApp teilen
  • Tangled ist eine Git-Kollaborationsplattform mit sozialen Funktionen auf Basis des AT Protocol und wurde so entwickelt, dass Entwickler die vollständige Kontrolle über ihren Code behalten, während Open-Source-Communitys autonom agieren können
  • Es setzt auf eine dezentrale Struktur für die Code-Zusammenarbeit, die die Stärken des föderierten Modells rund um ActivityPub (Forgejo) und des vollständig P2P-basierten Modells von Radicle kombiniert
  • Das zentrale Konzept „Knot“ ist ein leichtgewichtiger, headless Git-Server, der sowohl persönliches Self-Hosting als auch Multi-Tenant-Umgebungen auf Community-Ebene unterstützt
  • Die App View (tangled.sh) bietet eine integrierte Ansicht von Repositories im gesamten Netzwerk, sodass sich Repositories auf unterschiedlichen Knots nahtlos durchsuchen, klonen und Beiträge dazu leisten lassen
  • Der Dienst befindet sich derzeit in der Beta-Phase und verfolgt mit Datenhoheit, niedriger Einstiegshürde und konsistenter User Experience zentrale Prinzipien, mit dem Ziel, künftig ein vollständig offenes dezentrales Git-Ökosystem aufzubauen

Überblick über Tangled

  • Tangled ist eine neue Plattform, die Entwicklern den Besitz an Code und Identität lässt und zugleich eine Git-Kollaborationsumgebung mit sozialer Interaktion bietet
  • Auf Basis des AT Protocol überträgt sie die Architektur dezentraler Social-Apps auf die Git-Zusammenarbeit
  • Ziel ist es, Code-Kollaboration wieder zu einem offenen und freudvollen Prozess zu machen

Dezentrale Modelle und das AT Protocol

  • Bei bestehenden dezentralen Modellen für Code-Kollaboration gibt es unter anderem folgende Ansätze
    • Forgejo (ActivityPub): Zusammenarbeit über Federation zwischen Servern
    • Radicle: eine vollständig P2P-(peer-to-peer-)basierte Struktur
  • Tangled kombiniert die Stärken beider Modelle und setzt dabei auf atproto mit zentral handhabbarer Identitätsverwaltung
  • Dadurch können Nutzer auch in einem dezentralen Netzwerk eine konsistente ID- und Authentifizierungsstruktur beibehalten

Die Knot-Struktur

  • Knot ist die Kernkomponente von Tangled und ein leichtgewichtiger Server, der es Nutzern ermöglicht, Git-Repositories selbst zu hosten
    • Es werden sowohl Single-Tenant- als auch Multi-Tenant-Konfigurationen unterstützt
    • Self-Hosting ist auch auf kleinen Geräten wie einem Raspberry Pi möglich
  • Tangled bietet standardmäßig einen kostenlosen gemanagten Knot-Service an
  • Durch diese Struktur entsteht ein dezentrales Git-Netzwerk, in dem persönliche Server und Community-Server natürlich miteinander verbunden sind

App View und integriertes Netzwerk

  • Die auf tangled.sh bereitgestellte App View dient dazu, die Repositories des gesamten Netzwerks in einer integrierten Ansicht darzustellen
  • Nutzer können auch bei Repositories auf anderen Knots problemlos klonen (clone) und beitragen (contribute)
  • Dieses Design beseitigt die Hürden dezentraler Umgebungen, ohne den bestehenden Git-Workflow zu verändern

Entwicklungsprinzipien

  • Das Tangled-Team hat für die Entwicklungsrichtung die folgenden drei Prinzipien festgelegt
    • 1. Datenhoheit — Alle Nutzer besitzen den von ihnen erstellten Code und die Metadaten direkt selbst
    • 2. Niedrige Einstiegshürde — Eine einfache Struktur und Oberfläche, damit jeder leicht teilnehmen kann
    • 3. Konsistente User Experience — Trotz dezentraler Struktur wird eine UX auf dem Niveau zentralisierter Dienste gewährleistet
  • Diese Prinzipien spiegeln sich in den technischen Entscheidungen von Tangled sowie im gesamten UI/UX-Design wider

Zugang und Community

  • Anfangs wurde der Dienst nur per Einladung (invite-only) betrieben; Entwickler konnten über den IRC-Kanal #tangled auf libera.chat teilnehmen
  • Inzwischen ist der offene Login verfügbar, und jeder kann den Dienst unter tangled.sh/login nutzen
  • Tangled befindet sich noch in einer frühen Phase, wächst aber weiter und prüft seine Funktionen intern durch eigenes Dogfooding

Fazit

  • Tangled ist ein Versuch, Git-Kollaboration zu einer wie ein soziales Netzwerk vernetzten Erfahrung auszubauen
  • Es zieht Aufmerksamkeit als neues dezentrales Git-Plattform-Ökosystem auf sich, das Autonomie, Zugänglichkeit und eine freudvolle Entwicklungskultur verbindet

Verwandte Beiträge

2 Kommentare

 
lamanus 2025-10-12

Da es keinen offiziellen Container gibt, ist die Ersteinrichtung etwas umständlich.
 
GN⁺ 2025-10-12
Hacker-News-Kommentare
  • Als Mitgründer von Tangled hatte ich kürzlich beim Austausch der OAuth-Bibliothek ein Problem, durch das neue Nutzer nicht zu den standardmäßigen knot- und spindle-Instanzen (interner Git-Hosting-Server und CI-Runner) hinzugefügt wurden; ich habe gerade einen Patch eingespielt, also sollte das Erstellen von Repositories nach dem Ausloggen und erneuten Einloggen wieder normal funktionieren; bei Fragen antworte ich jederzeit gern
    • Die erste Frage ist, ob man auf dem tngl.sh-PDS den Handle ändern oder das Konto löschen kann. Die zweite betrifft die Ressourcen, die man zum Neuaufbau und Betrieb einer AppView braucht. Zum Beispiel: Wenn man eine PDS-basierte AppView erstellt, die wie bei Cloudflare Pages einfach einen statischen Website-Ordner hochlädt und direkt ausliefert, muss der Betreiber der AppView dann die Kosten für hohen Traffic vollständig tragen? Mich interessiert, wie in so einer Struktur die Betriebsbelastung aussieht
    • Tangled hat den Ausdruck „social-enabled“ verwendet, was offenbar mit dem AT-Protokoll zu tun hat. Mich interessiert, ob Tangled künftig vielfältigere soziale Funktionen plant oder ob damit einfach nur die Unterstützung des AT-Protokolls gemeint ist
  • Ich finde dieses Projekt wirklich großartig; mir gefällt der Versuch, die monopolartige Struktur bestehender Code-Forge-Dienste aufzubrechen. Ich interessiere mich für diesen Bereich, weil ich Code Forges für ineffizient halte, wenn sie versuchen, zu viele Probleme auf einmal zu lösen. Die meisten Forges bündeln Git-Repositories, Web-Viewer, Kollaborationstools, CI/CD-Pipelines, Aufgabenverwaltung und vieles mehr an einem Ort. Ich denke aber nicht, dass diese Funktionen zwingend zusammengehören. Wenn man zum Beispiel keinen direkten Zugriff auf das Git-Repository braucht, könnte man einen vollständig statischen Web-Viewer wie https://pgit.pico.sh anbieten, oder es könnte einen separaten Server geben, auf dem man Patches verteilt, lokal reviewt und verwaltet (https://pr.pico.sh). Es reicht völlig aus, auf einem VPS einfach ein Bare-Git-Repository zu hosten, und das ist sehr einfach. Git ist bereits ein verteiltes System; dass es wegen anderer Zusatzdienste wieder zentralisiert wird, halte ich für ein Anti-Pattern
    • Die Aussage „Git ist bereits verteilt“ hört man oft, aber tatsächlich ist das Konzept von Verteilung an manchen Stellen unscharf. Git selbst ist weniger auf Verteilung fokussiert, sondern basiert meist auf Master-Slave-Protokollen wie HTTP, wodurch sich am Ende doch immer wieder Zentralisierungstendenzen ergeben
    • Wenn es viele einzelne Dienste gibt, entsteht ein Vertrauensproblem. Prüft man einen einzigen Dienst, der 80 % der Anforderungen erfüllt, oder validiert man zehn separate Dienste einzeln? Dazu kommen Skaleneffekte in der Infrastruktur und Vorteile durch die Integration vieler Funktionen. Deshalb bevorzugen noch immer viele monolithische Lösungen. Letztlich ist das eine Abwägung beim Developer Experience
    • Ein Git-Remote-Repository auf einem VPS einzurichten ist wirklich einfach; sobald man per ssh zugreifen kann, funktioniert es sofort. Das eigentliche Kernproblem ist meiner Meinung nach „lock-in“. Warum konzentrieren sich GitHub und ähnliche Anbieter eher auf lock-in als auf den eigentlichen Service? Dahinter stehen Finanzierung und Geschäftsmodell. Diese Kette aus Zentralisierung → lock-in → Gewinn taucht bei vielen Diensten immer wieder auf. Wenn ein Dienst nicht aus dem Service selbst Profit machen kann, scheint dieses Phänomen kaum vermeidbar zu sein
    • Technisch ist die Trennung der Funktionen nicht unmöglich, aber es gibt auch wirtschaftliche Probleme (jede einzelne Funktion bringt nicht genug ein, um separat erhalten zu werden) und Usability-Probleme (Menschen wollen den Komfort eines „batteries included“-Angebots). Auch bei Open Source gibt es oft Fälle, in denen die Wirtschaftlichkeit ignoriert wird, aber am Ende verschwinden die meisten Projekte, wenn eine einzelne maintainer-Person ausfällt. Selbst die erfolgreichsten Open-Source-Projekte werden meist von Corporate-Sponsoren oder unterstützenden Engineers getragen
    • Es muss nicht zwingend getrennt werden, aber integriert ist es eben deutlich bequemer
  • Ich habe die Nachricht über die Jujutsu-Unterstützung kürzlich auf der JJ Con gesehen; Details gibt es unter https://blog.tangled.org/stacking
    • Dieser Dienst unterstützt tatsächlich stacked PRs. GitHub hat das seit Jahrzehnten nicht hinbekommen. Wenn man es intern privat nutzen müsste, ist es allerdings schade, dass unklar ist, wie man eine Tangled-Instanz so konfiguriert, dass sie nicht mit externen Netzwerken verbunden ist
  • Ich denke, GitHub ist nicht mehr vertrauenswürdig. Selbst wenn nur der OSS-Stack auf das AT-Protokoll oder ein anderes offenes Netzwerk umzieht, wäre das ein guter Weg, sich gegen Risiken durch Großkonzerne, Zensur usw. zu schützen. Solche Versuche begrüße ich sehr
    • Die meisten Menschen wollen aber keinen eigenen Server betreiben. Vermutlich können das nur große OSS-Organisationen stemmen. Selbst dann ist es schwierig, mehr als PRs per E-Mail anzubieten
  • Ich war unter den ersten 100 Personen, die sich bei tangled angemeldet haben. Die Roadmap für PR-Reviews im Stil gestapelter Patches und die Geschwindigkeit der Funktionsverbesserungen haben mich beeindruckt, und auch die Energie in der Community wirkt auf mich sehr positiv. Ich bin sehr gespannt, wie sich das weiterentwickelt. Wenn es auf diese Weise konsequent vorangeht, denke ich, dass sich eine deutlich bessere Erfahrung, grundlegendere Kontrolle und langfristige Nachhaltigkeit erreichen lassen
  • Ich interessiere mich sehr für stärker verteilte Formen der Git-Zusammenarbeit. Mich würde interessieren, was ihr als das größte Hindernis für eine breitere Verbreitung seht: Serverbetrieb, Verwaltung privater Schlüssel oder am Ende doch Netzwerkeffekte?
    • Die größte Hürde sind Spam, illegale Inhalte und Moderation im Allgemeinen. Da ein PDS auf beliebigen Domains laufen kann und ein einzelnes PDS unbegrenzt viele Nutzer aufnehmen kann, führt das oft zu Erfahrungen, die Vertrauen untergraben. Was macht man zum Beispiel, wenn Leute massenhaft E-Books oder TV-Serien in Git-Repositories hochladen? Oder wenn ein Projekt wegen eines politischen Themas mit Spam-Angriffen überzogen wird? Das Gute am AppView-Konzept ist, dass ein zentrales Moderationsteam wie bei Bluesky konsistente Richtlinien anwenden kann. Jeder kann zwar im Prinzip beliebige Dinge hochladen, aber am Ende kann das Frontend selektiv kuratieren. Gleichzeitig sind auch zentrale Moderationsentscheidungen immer umstritten. Das ist einer der Gründe, warum ich die Last und Verantwortung eines vollständig verteilten Netzwerks nicht tragen möchte. Die Offenheit des AT-Protokolls ist gegenüber Diensten wie Twitter ein Vorteil, aber im Gegenzug braucht man auch ein System, in dem alltägliche Verwaltung und Autorisierung konzentriert organisiert sind. Persönlich frage ich mich aktuell, ob sich überhaupt jemand freiwillig als Betreiber eines „großzügigen“ Radicle-Seed-Nodes melden würde, der anonyme Git-Uploads erlaubt
    • GitHub ist kostenlos, Dezentralisierung kostet Geld
    • Ich bin mit Tangled sehr zufrieden, weil man Git damit unabhängig nutzen kann, ohne selbst Server zu betreiben. Der größte Nachteil ist, dass der Dienst noch zu neu ist. Es fehlt noch an allgemeiner Bekanntheit, und viele wissen nicht, was Bsky und PDS überhaupt bieten. Mehr Funktionen und alternative Clients wären wünschenswert. Trotzdem haben Early Adopter meiner Meinung nach bereits jetzt eine sehr gute Erfahrung. Ich freue mich auf den Tag, an dem mehr Entwickler diese Erfahrung machen können
  • Ich habe mich über die Unterstützung von CI-Pipelines gefreut, war aber etwas enttäuscht, dass das Ganze GitHub Actions ähnelt. Ich denke nicht, dass man einfache sequentielle Ausführung unbedingt in YAML beschreiben muss; dafür reicht auch ein bash-Script. Pipeline-YAML ist meiner Ansicht nach sinnvoll, wenn es nicht den Programmfluss, sondern Abhängigkeiten (DAG) ausdrückt. Buildkite ist in dieser Hinsicht deutlich besser
  • Morgen kommt dann wohl eine No-Code-Business-Plattform namens „Spaghetti“ und ein wichtiger Datentresor-Dienst namens „Lock-in“ heraus
  • Ich bin in der Firma leider gezwungen, eine öffentliche GitHub-Org zu verwenden. Mich würde interessieren, ob man Code-Reviews (CR) in tangled machen und anschließend mit GitHub synchronisieren kann, sodass die Review-Erfahrung mit dem jj-Tool erhalten bleibt
  • Mich würde interessieren, ob man Tangled für Enterprise-/Private-Einsätze einführen kann. Der stacked-diff-Review-Flow scheint sehr gut zu Unternehmensabläufen zu passen
    • Es gibt diese Möglichkeit; aktuell wird über eine vollständig air-gapped und von AT getrennte Version von Tangled gesprochen. Das ist allerdings ein ziemlich großes Vorhaben und kurzfristig schwer umzusetzen
    • Derzeit existiert noch keine klar definierte separate Enterprise-Lösung; die zugehörige Issue-Diskussion findet sich unter https://tangled.org/@tangled.org/core/issues/60