Gitea: Federation für Organisation, Repositories und Benutzer

Es würde wahrscheinlich ausreichen, föderierte Repositories zu unterstützen

@kolaente Die Föderationsfunktion macht ausdrücklich für Benutzer Sinn. Wenn Sie Repositories teilen möchten, sollten Sie die Spiegelfunktion verwenden. Für den Projektmanager wäre es jedoch sehr praktisch, Benutzer aus anderen Git-Instanzen hinzuzufügen.

Siehe auch Nr. 184 (ist das ein Duplikat davon?)

@strk irgendwie, aber ich denke, dieser geht weiter

@strk Irgendwie. Aber dieses Problem beinhaltet eine vollständige Integration der Federation-Funktion für die Organisation, nicht nur für Pull-Requests.

Sie meinen für die Autorisierung von Remote-Benutzern?
Da halte ich es für sinnvoll, "Föderation" in viele verschiedene kleine aufzuteilen
Dinge zu implementieren, oder ein einzelnes Ticket würde einfach zu groß werden.

@strk Ich stimme der Idee zu, dieses Ding in viele Tickets aufzuteilen. Dieses Ticket könnte das Benutzerföderationsticket sein, nicht wahr? Aber ich möchte keine Authentifizierung für Benutzer anderer Plattformen. Ich möchte die Möglichkeit haben, andere Benutzer hinzuzufügen. Der Benutzer erhält eine Einladung von der Gitea-Instanz des Benutzers. Er wird von seiner Instanz aus auf das Repository oder die Organisation zugreifen.

Um jemandem in einem Verbund Berechtigungen zu erteilen, muss man dazu in der Lage sein
Identifizieren Sie diese Person (eine globale Adresse). Wie Sie bereits erwähnt haben, ist owncloud I
denke, owncloud verwendet "@" als Bezeichner, aber ich weiß nicht was
Protokoll, das es dafür verwendet. Friendica/GNUSocial und andere OStatus-Implementierung
Verbände können auch "@" Zuordnung zu etwas anderem über
der Webfinger-Standard (der offen ist, um verschiedene Spezifikation zu ermöglichen
Protokolle). Eine andere Community (die von IndieWeb, siehe indieweb.org) verwendet
Webadressen zur Identifizierung von Personen, wie sie bei OpenID bis Version 2.0 verwendet werden.
Neue OpenID (OpenID-Connect) nutzt wieder Webfinger.

Ich denke, dass der Webfinger-Standard eine gute Lösung sein könnte. Aber ich denke, dass es auch mit der Git-E-Mail eines Benutzers in Konflikt geraten könnte.

Wo ist der Konflikt?

Was ich an Webfinger nicht mag, ist, dass es die Kontrolle darüber braucht
der Domänenstamm (den Sie mit OpenID-URL nicht haben).

In Bezug auf „Welchen Standard wollen wir wählen“ möchte ich Sie nur auf ActivityPub hinweisen, das derzeit von der Social Federation-Arbeitsgruppe des W3C fertiggestellt wird. Einige Projekte, die es implementieren (oder derzeit daran arbeiten), sind pump.io, Mastodon und MediaGoblin.

Sie verwenden WebFinger jedoch nicht, da sie die Idee eines festen bekannten Pfads nicht mögen, aber es gibt Ideen zur Interoperabilität .

Diese Funktion wird wirklich das Spiel verändern; keybase.io hat kürzlich clientseitig verschlüsseltes Git herausgebracht, das ist auch interessant.

Ich möchte nur darauf hinweisen, dass ActivityPub jetzt fertig ist.

Das Hinzufügen von Unterstützung für AP würde Gitea mit einer wachsenden Anzahl von Verbundservern wie Mastodon, PeerTube, NextCloud und HubZilla kompatibel machen und seine Reichweite erheblich erweitern, ganz zu schweigen von einem herausragenden Unterscheidungsmerkmal gegenüber GitLab.
Es hätte auch das Potenzial, GitHub als Go-to-Hosting für Open-Source-Projekte zu entthronen, da die meisten für den Community-Pull-Request-Workflow hier sind, den AP auf dezentralisierte Weise ermöglichen würde, wodurch die Privatsphäre erhöht und ein Single Point of Failure beseitigt wird ein großer Prozentsatz der Freie-Software-Community.

Jedenfalls hoffe ich, dass dies umgesetzt wird, es hat das Potenzial, revolutionär zu sein!

Wie bereits im Chat erwähnt, ist ActivityPub in go ein PITA, da es in einer statischen Sprache wie go schwierig ist.

@tboerger Interessant. Die ActivityPub-Spezifikation ist ziemlich vererbungslastiges OO, aber das sollte in Go mit Struct-Einbettung modellierbar sein, aber soweit ich weiß, gibt es nichts Vergleichbares zu serde in Rust (https://docs.serde. rs/serde_json/value/index.html), was die Dinge sehr vereinfacht, aber es gibt einige Anstrengungen , ActivityPub in Go zu implementieren, was ein guter Anfang sein kann, da es nicht nur bereits json-ld Parsing implementiert, sondern auch definiert das Kernvokabular für ActivityStreams.

An welche konkreten Belästigungen denken Sie hier?

@MatejLach Ein weiteres Projekt https://github.com/go-fed/activity

Relevanter Vorschlag im Gogs-Repository:
https://github.com/gogs/gogs/issues/4437

Im Repository von Gitlab:
https://gitlab.com/gitlab-org/gitlab-ee/issues/4517

Hallo! ActivityPub-Mitherausgeber hier. Ich bin im Moment ziemlich beschäftigt, aber ich würde gerne sehen, dass dies geschieht ... wenn Sie Fragen haben, können Sie mich gerne anpingen oder unter #social auf irc.w3.org fragen

Bitte zögern Sie nicht, mich auf Mastodon zu kontaktieren, wenn Sie Fragen/Bedenken/Kommentare bezüglich der von @jas99 erwähnten https://github.com/go-fed/activity-Bibliothek haben. Ich habe selbstverständlich ein berechtigtes Interesse am Ausgang der Entscheidung, gebe aber gerne offen Auskunft über meine Erfahrungen im Schnittpunkt go+ActivityPub. Ich stimme @tboerger zu, dass die Implementierung von ActivityPub in go eine steile Klippe ist.

Vielleicht könnten wir ein neues Repository namens index erstellen und dafür die neue Domain index.gitea.io einrichten?

Warum brauchen wir einen Indexserver? @Lunny

Wäre großartig, wenn wir verschiedene Projekte haben könnten, die eine gemeinsame Implementierung des ActivityPub-Protokolls diskutieren (dh die Verwendung derselben Erweiterung für Verben usw.). Dies würde es Benutzern von Gitea, Gogs und Gitlab ermöglichen, nahtlos zusammenzuarbeiten, genau wie Benutzer verschiedener Social-Media-Plattformen, die sich zusammenschließen, nahtlos diskutieren können.

Könnte dies der Ort sein? -> https://github.com/git-federation/gitpub

@jaywink tolle Idee!

Das wäre erstaunlich! Ich denke, Nextcloud (/Owncloud) ist das perfekte Beispiel dafür, wie dies mit der idealen Implementierung funktionieren könnte, wie @JonasFranzDEV vorgeschlagen hat.

Wenn ich mit Nextcloud einen Ordner für einen Benutzer auf einer anderen Instanz freigeben möchte, kann ich dies ganz einfach tun und einen freigegebenen Ordner für beide Instanzen einrichten.

Wenn ich das für ein Repository tun könnte, das auf meiner Gitea-Instanz gehostet wird, indem ich einem Benutzer auf einer anderen föderierten Instanz Zugriff auf das Repository gewähre, wobei dieses Repository dann in ihrer Gitea-Oberfläche mit voller Fähigkeit zur Interaktion mit Problemen usw. erscheint (mit einer klaren Bezeichnung in der UI, dass dieses Repo auf einer anderen Instanz gehostet wurde), das wäre ziemlich erstaunlich.

Das diskutierte Ziel, einen gemeinsamen Standard zwischen Gitea und anderen selbst gehosteten Open-Source-Projekten (wie GitLab CE) einzuführen, ist definitiv sinnvoll, und es wäre großartig, wenn dies angenommen würde, um eine Föderation zwischen Gitea, Gogs, GitLab usw. zu ermöglichen. Die Migration von GitHub für private Projekte ist einfach, ohne dass wirklich etwas verloren geht, aber für öffentliche Open-Source-Projekte müssen wir anerkennen, dass ein großer Vorteil von GitHub die Community ist. Ich habe viele Projekte tatsächlich auf GitHub entdeckt. Wenn es eine Möglichkeit gäbe, beliebte Projekte zu föderieren, wäre der Aktivitätsfeed der Benutzer (dh die Möglichkeit, einem Freund auf einer anderen Instanz zu folgen und seine Aktivitäten zu verfolgen, gemochte Projekte, mit Berücksichtigung der Datenschutzeinstellungen usw.) hervorragend - wenn das möglich wäre.

Federated Pull Requests wären ein großartiger erster Schritt in diese Richtung (#184) und wahrscheinlich das derzeit wichtigste fehlende Feature.

11 Monate seit dem letzten Kommentar hier.. Ich frage mich, ob es noch Pläne gibt?

Wenn es eine Art Standard gibt, auf den man sich geeinigt hat, dann ja

Aktuelle Diskussionen finden im Rahmen des Forgefed-Projekts statt, also folgen Sie dort, wenn Sie mehr wissen möchten: https://github.com/forgefed/forgefed

Wie @lafriks erwähnte, können verschiedene Projekte, sobald es einen vereinbarten Standard gibt, diesen implementieren.

Die korrekte URL für das Forgefed-Projekt lautet jetzt https://notabug.org/peers/forgefed

Scheint, als ob dies jetzt von größter Bedeutung sein sollte, wenn man bedenkt, dass Github jetzt Konten von Personen aus ganzen Ländern entfernt.

ForgeFed hat jetzt auch ein Diskussionsforum . Wäre toll, jemanden von Gitea mit einzubeziehen.

+1 dafür. Von einer lokalen, selbst gehosteten Instanz aus zu arbeiten, aber aufgrund dieser Wahl nicht isoliert zu sein, wäre wirklich das Beste aus beiden Welten.

Die ForgeFed -Arbeitsgruppe würde dringend Entwickler aus den aktuellen Schmieden brauchen, um Kommentare abzugeben: https://talk.feneas.org/t/working-group-instructions/196

Ich möchte nur hinzufügen, dass dies, bevor Microsoft eine Massenmigration weg von Github inspiriert hat, kein Killer-Feature gewesen wäre ... JETZT ist es das. Immer weniger Repos für OS-Projekte, die ich recherchiere, befinden sich jetzt auf Github (vielleicht hier gespiegelt).

Ich habe gelesen, dass sich die Github-Commit-Historie wie ein Lebenslauf lesen kann und dass einer der Gründe, warum die Softwarewelt so karrieremobil ist, darin besteht, dass eine Person wertvolle Fähigkeiten selbst erlernen und sie EINFACH DEMONSTRIEREN kann (öffentliche Github-Historie) und so qualifizieren für besseres Einkommen/usw. Wenn Ihr Beitragsverlauf über Dutzende von privaten Servern verteilt ist, ist er VIEL weniger sichtbar/nützlich.

Außerdem könnte jeder dieser Server jederzeit ausfallen und dieser Teil Ihres Verlaufs ist jetzt weg. Eine ordnungsgemäße Implementierung von föderierten Repositories würde bedeuten, dass ich an Dutzenden von Projekten auf Dutzenden von Instanzen (aus meiner Instanz) teilnehmen könnte, und wenn sie ALLE ausfallen würden, hätte ich immer noch mein „föderiertes Git-Profil“.

Verlinkung zur ForgeFed-Roadmap (es gibt Fördermittel für diejenigen, die daran arbeiten):

https://notabug.org/peers/forgefed/issues/87

Vielleicht könnte gitea für eine einfache Implementierung einen ipfs -Knoten im Hintergrund ausführen, der lokale Repository-Dateien hostet (unter Verwendung von ipns , um auf die neuesten Versionen der Repositorys zu verweisen). Wir könnten dann eine einfache Gossip -Protokollimplementierung haben, um andere Gitea-Instanzen zu finden und IPNs-Hashes und vorläufige Daten (Sterne, Name) zu erhalten.
Der Vorteil der Verwendung von ipfs wäre, wenn Benutzer auf einer Instanz Repositorys auf anderen Instanzen anzeigen oder verzweigen möchten, dies zum Hosten von Teilen dieses Repositorys beitragen und den Zugriff auf das Repository für das gesamte Netzwerk beschleunigen würde.

Die Verwendung von ipfs/ipns könnte auch zum Verteilen von Benutzerdaten wie markierten Repositories, Pull-Requests, Bio usw. verwendet werden. Jeder Knoten würde nur Namen und ipns-Hashes für Benutzer in anderen Netzwerken speichern, die der Instanz wichtig sind, und es wäre trivial, sie anzufordern Profildaten für unbekannte Benutzer.

ipfs hat bereits eine Go- Implementierung und zum Beispiel Discovery könnte so etwas verwendet werden.

Hier ist keine Peer-to-Peer-Speicherung erforderlich, was Sie beschreiben, scheint nicht erforderlich zu sein oder gar mit dem vorliegenden Problem in Zusammenhang zu stehen. Ich glaube nicht, dass es Interesse gibt, sich vom Git-Speicherformat und -Übertragungsprotokoll zu entfernen. Vielleicht sollten Sie ein separates Thema eröffnen, wenn Sie hier einen Vorteil sehen (ich jedenfalls nicht).

Hier ist keine Peer-to-Peer-Speicherung erforderlich

Ich denke, Gitea würde stark vom Peer-to-Peer-Sharing von Repositories profitieren, so dass beliebte Repos im Falle eines Ausfalls von Instanzen überflüssig wären. Während jemand ein Repository einfach auf seine eigene Instanz spiegeln kann, würde dies die Entwicklung eines Projekts fragmentieren, wenn es keinen zentralen Ort gibt, an den man sich binden kann. Wenn das Git-Protokoll auf IPFS geschichtet wäre, würde es eine Deduplizierung ermöglichen, wenn Projekte auf einer einzelnen Instanz verzweigt würden (damit keine vollständige Kopie gespeichert werden müsste).

Was Sie beschreiben, scheint nicht erforderlich zu sein oder mit dem vorliegenden Problem zusammenzuhängen.

Der Grund, warum die Föderation so nützlich ist (und warum die Leute sie so sehr wollen), ist, dass sie die Zusammenarbeit über Instanzen hinweg ermöglicht. Das InterPlanetary Name System (IPNS) verhält sich identisch mit OpenID, da es verwendet werden kann, um einen Benutzer zu identifizieren, der die Erlaubnis hat, bestimmte Daten zu aktualisieren (z. B. seine Repositories und sein persönliches Profil). Eine IPNS-Adresse könnte einen Benutzer einer anderen Instanz eindeutig identifizieren, ohne dass dieser Benutzer notwendigerweise an eine bestimmte Instanz gebunden werden muss. Lassen Sie uns ein Beispiel geben:
Alice hostet selbst eine Instanz von gitea auf aliceland.net
Wenn Alice ein neues Konto erstellt, erstellt gitea ein leeres Profil, hostet es auf IPFS und generiert dann eine eindeutige IPNS-Adresse, die auf dieses Profil verweist. Immer wenn Alice ein neues Repository erstellt oder ihr Profil auf irgendeine Weise aktualisiert, erstellt gitea (hinter den Kulissen) einen neuen IPFS-Eintrag, löst den alten und weist ihm Alices IPNS-Adresse neu zu.
Nehmen wir nun an, Bob möchte eine Zusammenführungsanforderung von seinem Spiegel des Repositorys auf bobland.net an aliceland.net senden.
Als Bob ursprünglich Alices Repo zu bobland.net geforkt hat, hat er sich das IPNS von Alices Repo sowie den IPFS-Speicherort des Commits notiert, von dem er geforkt hat.
Wenn Bob eine Zusammenführungsanfrage öffnen möchte, schreibt er seine Nachricht und dann fügt bobland.net die folgenden Dinge in einen IPFS-Block ein:

• Bobs IPNS-Benutzeradresse
• Die IPFS-Adresse der Commits, die Bob abrufen möchte
• Die IPFS-Adresse des Commits in Alices Repository, die geändert werden soll
• Bobs Nachricht und Titel für die Zusammenführungsanforderung
• Signatur von Daten mit Bobs privatem IPNS-Profilschlüssel

Bobland.net sendet dann die IPFS-Adresse an aliceland.net, die dann entscheiden kann, sie vollständig zu ignorieren ODER die Adresse zu parsen, die Commits zu überprüfen, eine IPNS-Adresse für den Kommentar-Thread zu erstellen (die auf alle Kommentare verweist) und dann zu benachrichtigen Alice, dass ein Typ namens Bob auf Instanz Bobland.net eine Zusammenführungsanforderung für 3 Commits über IPFS gesendet hat. Die Kommentare würden auch über IPFS gehostet und über eine IPNS-Adresse zugänglich sein.
Dieses Muster der Verwendung von IPNS für veränderliche Daten (wie ein Kommentar-Thread) und IPFS für unveränderliche Daten (wie Kommentare und Commits) kann für die meisten Föderationen zwischen Instanzen angewendet werden.

Ich glaube nicht, dass es Interesse gibt, sich vom Git-Speicherformat und -Übertragungsprotokoll zu entfernen.

Dieser Verbundansatz müsste sich nicht vom Git-Format entfernen. Git kann einfach auf ifps geschichtet und gespeichert werden (wobei auch die Vorteile der Deduplizierung genutzt werden). Das Merkle Tree-System von Git muss nicht unbedingt in IPFS integriert werden (obwohl das cool wäre) und das Git-Übertragungsprotokoll wäre immer noch dasselbe, IPFS würde nur die Kommunikation zwischen Instanzen moderieren.

Kannst du einfach ein separates Thema aufmachen? Hier geht es um etwas Bestimmtes, und ForgeFed arbeitet bereits an einem Protokoll. Noch besser, bringen Sie es mit ihnen zur Sprache.

Probleme mit Kommentaren wie „was ist mit ipfs/filecoin/blockchain“ anzuhäufen, erscheint einfach unhöflich.

+1

GitLab diskutiert dieses Feature ebenfalls: https://gitlab.com/gitlab-org/gitlab/-/issues/6468

Ich habe vor ein paar Tagen als FYI den gitea dev discord angepingt und habe proaktiv versucht, einige der Leute hinter ForgeFed zu erreichen, da es schön wäre, eine Instanz zu bekommen, wenn go-fed v1 fertig und dokumentiert ist von gitea auf ActivityPub eingebunden, obwohl es kein geringer Aufwand ist. Ich denke, die Gitea-Leute sind mit anderen Prioritäten beschäftigt. Leider hatte ich keinen Erfolg, einen der ForgeFed-Leute zu erreichen. :(

Einige von uns in der ActivityPub-Community experimentieren nach der APConf2020 damit, einen leichten Basis-Dokumentationsprozess auf einer Gitea-Instanz zu haben, und es fühlt sich seltsam an, noch nicht in der Lage zu sein, sich damit zu verbinden.

Git verfügt bereits über alle Funktionen, die für die dezentrale Spiegelung erforderlich sind, die einzige Funktionalität, die fehlt, ist die, die notwendig ist, um sie zu koordinieren, was genau das ist, was ForgeFed tut. IPFS muss nicht hier sein, und angesichts dessen, wie katastrophal ihr Mainnet-Start verlief, bin ich mir nicht sicher, ob es sicher ist, zu eng mit anderen Projekten von Protocol Labs verbunden zu werden.

Ich bin daran interessiert, an einer der bestehenden Initiativen mitzuarbeiten. Versuchen wir, eine Arbeitsgruppe zusammenzustellen. Kann diesen Matrix-Kanal zur weiteren Diskussion vorschlagen #n oteworthy:tincan.community