Die Föderation der Forges ist notwendig
(blog.tangled.org)- Open-Source-Zusammenarbeit sollte idealerweise auf einer Kombination verteilter Protokolle beruhen, die Code-Übertragung und Kommunikation getrennt übernehmen, statt stark von einem einzelnen Anbieter abhängig zu sein
- Code-Zusammenarbeit erfolgte ursprünglich über die Kombination git und E-Mail, verlagerte sich später zu git und der GitHub-Website und setzt sich mit ForgeFed als Kombination aus git und ActivityPub sowie mit Tangled als Kombination aus git und AT protocol fort
- Tangled föderiert Ereignisse zwischen git-Servern, nennt jeden Server einen knot und unterstützt Repository-Zusammenarbeit auch über Servergrenzen hinweg, serverübergreifende Forks sowie Pull Requests zu Repositories auf anderen Servern
- Für den Authenticated Transfer rund um den Code nutzt Tangled AT und verarbeitet dabei issues, pull requests, Event-Timelines, follows und stars gemeinsam; außerdem wird es für Einladungen von Mitwirkenden und den Austausch öffentlicher SSH-Schlüssel verwendet
- Der Ansatz ähnelt in vieler Hinsicht dem Betrieb einer eigenen cgit-Instanz und dem Versenden von Patches per E-Mail, zeigt aber zugleich eine Richtung auf, die sich aus der GitHub-Monokultur lösen und die soziale Seite sowie den Spaß an Zusammenarbeit bewahren will
Warum die Föderation von Forges nötig ist
- Eine Struktur, in der Open-Source-Zusammenarbeit zu großen Teilen von einem einzelnen Anbieter abhängt, ist nicht wünschenswert; zugrunde liegt die Sicht, dass verteilte Protokolle langlebiger sind als zentralisierte Systeme
- Für die Code-Zusammenarbeit wurden schon immer zwei Protokolle parallel genutzt: eines für die Code-Übertragung, das andere für die Kommunikation
- Der frühe Ablauf war die Kombination aus git und E-Mail
- Später wechselte das zu einer Kombination aus git und der GitHub-Website
- ForgeFed setzt auf die Möglichkeit einer Kombination aus git und ActivityPub
- Tangled wird als Kombination aus git und AT protocol aufgebaut
- Tangled föderiert Ereignisse zwischen git-Servern und nennt jeden Server einen knot
- Repository-Zusammenarbeit ist unabhängig vom jeweiligen Server möglich
- Serverübergreifende Forks werden unterstützt
- Man kann in ein Repository auf dem eigenen Server pushen und danach einen Pull Request zu einem Repository eröffnen, das auf einem vollständig anderen Server gehostet wird
- Dieser Ansatz ähnelt in vieler Hinsicht dem Betrieb einer eigenen cgit-Instanz und dem Versenden von Patches per E-Mail
Welche Rolle Tangled übernimmt
- Tangled verwendet AT für den Authenticated Transfer von Ereignissen rund um den Code
- Es wird für die Übermittlung von Ereignissen wie issues und pull requests genutzt
- Auch soziale Funktionen wie Event-Timelines, follows und stars werden gemeinsam darüber abgewickelt
- Vouches sollen bald ebenfalls hinzukommen
- AT wird auch für Einladungen von Mitwirkenden und den Austausch öffentlicher SSH-Schlüssel verwendet, während im Übrigen das bestehende git unverändert genutzt wird
- Open Source muss sich aus einer Monokultur wie GitHub lösen, zugleich aber die soziale Seite und den Spaß an der Code-Zusammenarbeit bewahren
- tangled alpha
- docs
- source
- discord
- bluesky
- twitter (x)
- feed
1 Kommentare
Hacker-News-Kommentare
Ich bin mir nicht sicher, wie viel besser das als Mastodon wird.
Es gibt eine vom App-Layer getrennte Hosting-Schicht, jeder kann seine eigenen Daten hosten, und Apps sammeln dann die Daten aller Hosts ein und zeigen sie an.
Deshalb gibt es so etwas wie Mastodon-artige Defederation dort gar nicht.
Wenn du mehr wissen willst, schau dir https://overreacted.io/open-social/ und https://overreacted.io/a-social-filesystem/ an.
Accounts werden auf einem PDS gehostet und die Einträge landen auch dort, aber was man in der App sieht, wird von einer AppView bereitgestellt, die Daten aus vielen PDS zusammenführt.
Deshalb fühlt sich das App-Erlebnis unabhängig davon, auf welchem PDS man ist, wie ein zentralisierter Dienst an; außerdem kann es mehrere AppViews geben, und man kann sie auch selbst hosten.
Über die Kosten dieser faktisch globalen Auffindbarkeit wie jetzt sollte man schon nachdenken, aber es ist trotzdem schwer, das einfach als ein weiteres Mastodon abzutun.
Man kann sich doch auch einfach nicht festlegen oder zu der Seite gehen, die man selbst für richtig hält.
Ich bin möglicherweise voreingenommen, weil ich im atprotocol-Umfeld ziemlich aktiv bin, aber ich nutze Tangled wirklich sehr gern.
Es kommt dem GitHub-Ersatz, den ich mir gewünscht habe, am nächsten; funktional ist es einfacher, aber im letzten Jahr war es mein wichtigster Social-/Git-Dienst für persönliche Open-Source-Projekte.
Mein Account ist https://tangled.org/did:plc:rnpkyqnmsw4ipey6eotbdnnf.
Ich mag, dass der soziale Graph, den ich von Bluesky kenne, weiterlebt und man so intuitiv die Menschen hinter Commits, PRs und Issues miteinander verbinden kann; auch das Login ist bequem, weil es wie bei anderen atproto-Diensten funktioniert.
Vor Kurzem kam auch eingebaute Unterstützung für statische Sites dazu, sodass man clientseitige Websites oder ein einfaches
index.htmldirekt aus dem Repo hosten kann.Spindles übernimmt die Rolle des Build-Systems bzw. der Actions, und auch wenn ich kein Nix-Fan bin, hat es für meinen Einsatzzweck ziemlich gut gepasst.
Die open API ist ebenfalls gut, sodass ich mithilfe atproto-basierter Standards leicht Darstellungen von Informationen bauen, Bots schreiben und ein paar Funktionen an npmx.dev anhängen konnte.
Man kann knot (Git-Server) und Runner (Spindles) selbst betreiben oder die gehosteten Varianten nutzen; der eigentliche Kern ist aber, dass die Social-Funktionen getrennt sind, sodass Gespräche in Issues oder PRs auf einer gemeinsamen Social-Layer weiterlaufen, selbst wenn der Git-Server separat ist.
Perfekt ist es nicht, und das alpha-Label in der Navbar ist nicht ohne Grund da, aber für Open-Source-Arbeit werde ich es wahrscheinlich weiter nutzen.
Ob das eine berechtigte Sorge ist, kann ich noch nicht gut einschätzen.
Die Stimmung in den Kommentaren ist ziemlich negativ, aber obwohl auch ich VC-Finanzierung skeptisch sehe, finde ich, dass Wettbewerb in diesem Bereich gefördert werden sollte.
So etwas zu diesem Zeitpunkt per Bootstrap zu starten, wirkt sehr schwierig oder faktisch unmöglich; ja, das Timing mit den GitHub-kritischen Beiträgen, die gestern oben auf HN standen, war sicher günstig, aber ich möchte solche Versuche trotzdem unterstützen.
Ich hoffe, dass es eine relevante Größenordnung erreicht.
Nach der Überschrift war ich interessiert, aber in dem Moment, in dem ich von VC-Finanzierung erfahren habe, war es für mich sofort raus.
Wenn ich mein Herzensprojekt, das kein Geld einbringt, auf eine Plattform stelle, dann möchte ich einen Ort wählen, bei dem die Wahrscheinlichkeit geringer ist, dass es in fünf Jahren zu einem rug pull kommt.
VC-Projekte müssen am Ende Rendite für ihre Investoren liefern, also rechne ich damit, dass so ein rug pull früher oder später kommt.
Deshalb nutze ich momentan lieber Dienste, bei denen ich zahlender Kunde bin oder als Mitglied einen Beitrag zahle und Stimmrechte bei Entscheidungen habe.
Deshalb sollten Nutzer diese Möglichkeit von Anfang an kennen.
Wenn die absehbare Realität so aussieht, mag ich Dienste nicht besonders, die trotzdem übertrieben idealistisch auftreten.
Lieber sollen sie Gebühren verlangen oder, wenn sie den Idealen wirklich folgen wollen, als non-profit starten oder wenigstens ihren Plan zur Monetarisierung klar offenlegen.
Dass es schwierig ist, ist klar, aber gerade wenn man auf Federation setzt, sollte das doch mit gleich hohen oder sogar niedrigeren Infrastrukturkosten machbar sein, nicht mit höheren.
Wenn dich das atproto-Datenmodell interessiert, habe ich unter https://overreacted.io/a-social-filesystem/ einen Einführungsartikel dazu geschrieben.
Er ist etwas lang, vermittelt aber das Gesamtbild ziemlich klar.
Das war der beste ATProto-Einführungstext, den ich bisher gelesen habe.
Gibt es zufällig ein Tag oder eine Liste, in der diese Artikel gesammelt sind?
Meiner Meinung nach brauchen wir keine Forge-Federation, sondern ein reichhaltigeres Git-Repo an sich.
Fossil ist mit der Integration von Tickets, Forum und Wiki als Teil des Repositories schon fast zu 90 % dort, und beim Klonen bekommt man all das gleich mit und kann es auch offline ansehen.
Man könnte also sogar im Flugzeug Antworten schreiben und sie, falls man die nötigen Rechte hat, sofort oder später nach Wiederherstellung der Verbindung synchronisieren.
Statt bestimmte Artefakt-Typen fest in ein VCS einzubauen, fände ich es aber besser, Apps im Repo zu haben, die dann festlegen, welche Artefakte erlaubt sind, welchen Regeln sie folgen und wer wann etwas hoch- oder herunterladen darf.
Die Forge würde dann nur diese Regeln durchsetzen und es für Webnutzer in der gewünschten Form rendern.
Dann wäre auch ein Umzug zu einer anderen Forge letztlich kaum mehr als ein Push des Repos.
Ich habe in letzter Zeit Dinge wie Ticket-Systeme oder Agenten als flat files in Git-Repos gebaut, und jetzt denke ich, dass ich das auf die Verwaltung des Repos selbst ausweiten sollte.
Das klingt großartig.
Das Kernproblem einer federated solution ist für mich letztlich der Cold Start.
Wenn man einem bestehenden großen Server beitritt, holt man sich genau das Zentralisierungsproblem zurück, vor dem man eigentlich wegwollte, bekommt dafür aber von Anfang an ein großes Netzwerk.
Wenn man dagegen einen eigenen Server aufsetzt, hat man null Netzwerk, null Auffindbarkeit, einen leeren Feed und muss andere Sites davon überzeugen, mit einem zu föderieren oder einen nicht zu blockieren, nur weil man ein Ein-Personen-Server ist.
Ich weiß nicht, ob nur ich das so empfinde oder ob ich Federation falsch verstehe.
Vielleicht ist das auch einfach ein spezifisches Mastodon-Problem.
Es ist so aufgebaut, dass zentrale AppViews einzelne Server zusammenführen und eine konsistente Einzelsicht wie in einem zentralisierten Netzwerk bieten.
AppViews kann jeder hosten.
atproto funktioniert nicht so, dass jeder Server wie ein halb isoliertes Gebiet agiert.
Eine gute Erklärung aus Sicht verteilter Systeme ist https://atproto.com/articles/atproto-for-distsys-engineers.
Wenn ein großer Server bei Moderation, Richtlinien, Inhalten oder technisch fragwürdig wird, kann man relativ leicht ausweichen, einen anderen recht großen Server aufbauen oder dorthin umziehen.
Das heißt, man kann mit gewisser Reputation und Größenordnung schon im Voraus Zufluchtsorte schaffen.
Mit alternativen Forges wie GitLab, Codeberg, freedesktop, Fedora oder Debian gibt es sie bereits; solange Sichtbarkeit und Auffindbarkeit eines Projekts erhalten bleiben, wären das ausreichend sichere Ausweichorte.
Aber nachdem ich dieses Projekt vor ein paar Tagen gesehen habe, dachte ich erstmals: Das könnte wirklich funktionieren.
Denn die Zielgruppe überschneidet sich stark mit Leuten, die an Self-Hosting gewöhnt sind.
Es muss nicht mein gesamtes Netzwerk dort sein; schon die Teilmenge, die realistisch dort auftauchen würde, wäre für mich nützlich genug.
Die Kosten für Frontend-Server dürften sehr niedrig sein, also scheint selbst ein nahezu permanenter Betrieb realistisch, während die eigentlichen Daten von anderen Hosts geliefert werden.
Dass Tangled VC-finanziert ist, gibt mir eher das Gefühl von Wachstumszwang als von Stabilität.
Ich sehe den Reiz daran nicht wirklich.
Selbst wenn es föderiert ist: Wenn die Entwicklung stoppt, wer soll dann Bugs beheben und die Wartung übernehmen?
Also Software, die vollständig reproduzierbar ist und sich insgesamt zu minimalen Kosten selbst hosten lässt.
VC-Finanzierung ist kein Selbstzweck, sondern nur ein Mittel; für die zwei indischen Gründer in Europa waren Fördergelder praktisch unrealistisch, weil es 4 bis 12 Monate oder länger gedauert hätte, bis überhaupt etwas geflossen wäre.
Der schnellste Weg, ein Team aufzubauen, Infrastruktur bereitzustellen und die Entwicklung zu beschleunigen, war VC, und sie haben laut eigener Aussage sehr stark auf Zielabgleich mit den Investoren geachtet und über sechs Monate gebraucht, um den passenden Partner zu finden.
Tangled trifft architektonisch einige interessante Entscheidungen, aber der Code selbst ist vergleichsweise einfach und wirkt, soweit ich ihn angesehen habe, nicht schwer zu pflegen.
Das meiste sind lose gekoppelte Go modules, dazu statisches HTML+CSS, ein wenig TypeScript und Nix für die Orchestrierung.
Wenn ich mich richtig erinnere, sind auch die Hardware-Anforderungen sehr gering, sodass bei der aktuellen Größe eine einzelne Person es selbst hosten könnte.
Ein großer Teil der tatsächlichen Infrastruktur wird ohnehin von den knots, spindles, PDS der Nutzer und vom atproto-Ökosystem insgesamt getragen.
Warum braucht es unbedingt VC, und warum nicht Unternehmenssponsoring wie bei Ladybird?
Und wenn die Investoren einen 10x-Return erwarten, warum sollte ich dann Zeit in ein Entwicklertool stecken, das später am Ende doch enshittified wird?
Das erinnert mich an den Witz: Wenn es 4 Standards gibt und man einen neuen baut, um alles zu vereinheitlichen, hat man am Ende 5 Standards.
Witz beiseite: Ich finde, es braucht stärkere Argumente dafür, warum ActivityPub nicht ausreicht, bevor man das Problem dezentraler Kommunikation noch einmal auf eine andere Weise lösen will.
Sie gegeneinanderzustellen ist ungefähr so, als zu fragen, warum man das Web braucht, wenn es doch E-Mail gibt.
ActivityPub funktioniert eher wie E-Mail: Server übernehmen die Rolle von Posteingängen und schicken sich gegenseitig Nachrichten.
atproto funktioniert dagegen eher wie das Web: Nutzer-Repositories hosten die Daten, und Apps sammeln diese Daten aus den Repositories ein und zeigen sie an.
Wegen dieser Topologie unterscheiden sich auch die Eigenschaften: Bei atproto bleibt das App-Erlebnis erhalten, auch wenn man das Nutzer-Hosting wechselt, und jeder kann neue Apps auf Basis bestehender Daten bauen.
ActivityPub erlaubt das nicht wirklich und ähnelt am Ende eher kleinen zentralisierten Diensten, bei denen Hosting und App gekoppelt sind und die sich gegenseitig Nachrichten schicken.
Es gibt auch https://gitworkshop.dev/ als relativ ausgereifte GitHub-Alternative auf Basis von Nostr.
Die Kernidee ist, dass Repositories auf mehrere GRASP-kompatible Nostr-Relays gelegt werden können und transparent über andere synchronisiert werden, wenn ein Server ausfällt.
Wenn man vertrauenswürdige Server auswählt, kommt das praktisch an 100 % Verfügbarkeit heran, und Repositories, Aktivitäten, Issues usw. sind kryptografisch signiert.
Schon der Name scheint gegen die Markenrichtlinie von git zu verstoßen.
https://git-scm.com/about/trademark
Bei manchen hieß es, der Browser unterstütze keine ssh- oder https-URL, bei anderen kam nur
Failed to load file treemit endlosem Laden.Deshalb finde ich die Beschreibung fairly mature nicht besonders überzeugend.
Ich bin sehr für Federation, aber den Nutzen einer Federation of Forges habe ich nie ganz verstanden.
Welche Daten sollen Forges untereinander überhaupt austauschen?
Warum sollte eine Forge für Blender mit einer Forge für Ubuntu verbunden sein?
Der größte Mehrwert, den ich aus GitHub ziehe, ist ein Single Sign-on, mit dem ich zwischen Projekten wechseln kann; unabhängige Forges könnten viel davon auch einfach über Social Login bieten, ganz ohne komplizierte Forge-Federation.
Wenn du eine Forge selbst hostest, findet deine Software niemand, außer du bist bereits ein großer Name wie Blender.
Deshalb ist mindestens ein GitHub-Mirroring fast schon Pflicht, damit der Code nicht im Nichts verschwindet.
Wenn man das vermeiden will und kleinere Forges gemeinsam konkurrenzfähig sein sollen, braucht man ein einziges Netzwerk, in dem Software unabhängig vom Host gefunden werden kann, und genau darauf zielt ForgeFed ab.
Es verringert auch die Reibung für neue Beitragende, die nicht jedes Mal ein dediziertes Forge-Login anlegen wollen, auch wenn das eher ein Nebeneffekt ist.
GitHub hat nur UI, Issues und PRs gut gelöst und damit auch für Einsteiger eine Arbeit über die Oberfläche ermöglicht, was dann zur Zentralisierung geführt hat.
Federation passt stärker zur Git-Philosophie, aber sie muss nicht bis zu einer extremen Form verteilter Systeme gehen, in der beim Ausfall eines Knotens das Upstream verschwindet oder gar nicht mehr auffindbar ist.
Git selbst löst das Verfügbarkeitsproblem nicht, und Federation kann diese Verfügbarkeit verbessern, ohne die dezentrale Philosophie aufzugeben.
Es braucht eine einfache Möglichkeit, Open-Source-Projekte auf verstreuten Servern zu finden.
Die GitHub-Projektsuche funktioniert nur innerhalb von GitHub.
Darüber hinaus würde das System auch resilienter werden, wenn ein Projekthost verschwindet, seine Richtlinien ändert oder von einer Regierung blockiert wird.
Außerdem zeigt eine AppView die Daten vieler PDS gebündelt in einer Oberfläche an.
Selbst wenn tangled.org enshittified würde, könnte man nahtlos über irgendeine andere AppView weitermachen, und tangled.org hätte keine privilegierte Stellung.
Social Login bei unabhängigen Forges hilft zwar auch, aber persönlich finde ich es besser, nur einen Account verwalten zu müssen, und dank des AT protocol bleiben die Daten selbst dann über andere AppViews zugänglich, wenn eine einzelne Forge verschwindet.