Gitea: Fédération pour l'organisation, les référentiels et les utilisateurs

Ce serait probablement suffisant pour prendre en charge les référentiels fédérés

@kolaente La fonctionnalité de fédération a un sens explicite pour les utilisateurs. Si vous souhaitez partager des référentiels, vous devez utiliser la fonction miroir. Mais il serait très pratique pour le chef de projet d'ajouter des utilisateurs d'autres instances de git.

Voir aussi #184 (est-ce une copie de cela ?)

@strk en quelque sorte, mais je pense que celui-ci va plus loin

@strk En quelque sorte. Mais ce problème inclut une intégration complète de la fonctionnalité de fédération pour l'organisation, pas seulement pour les demandes d'extraction.

Vous voulez dire pour l'autorisation des utilisateurs distants ?
Comme je pense qu'il est utile de scinder la "fédération" en plusieurs petits
choses à mettre en œuvre, ou un seul ticket deviendrait tout simplement trop gros.

@strk Je suis d'accord avec l'idée de diviser cette chose en plusieurs tickets. Ce ticket pourrait être le ticket de fédération d'utilisateurs, n'est-ce pas ? Mais je ne veux pas d'authentification pour les utilisateurs d'autres plates-formes. Je veux pouvoir ajouter d'autres utilisateurs. L'utilisateur recevra une invitation de l'instance Gitea de l'utilisateur. Il accédera au référentiel ou à l'organisation depuis son instance.

Accorder des autorisations à quelqu'un dans une fédération nécessite de pouvoir
identifier cette personne (une adresse globale). Comme vous l'avez mentionné owncloud je
pense qu'owncloud utilise "@" comme identifiant, mais je ne sais pas quoi
protocole qu'il utilise pour cela. Mise en œuvre de Friendica/GNUSocial et d'autres OStatus
les fédérations peuvent également utiliser "@" mappage à autre chose via
la norme Webfinger (qui est ouverte pour permettre de spécifier différentes
protocoles). Une autre communauté (celle d'IndieWeb, voir indieweb.org) utilise
des adresses Web pour identifier les personnes, telles qu'elles sont utilisées avec OpenID jusqu'à la version 2.0.
Le nouvel OpenID (OpenID-Connect) utilise à nouveau Webfinger.

Je pense que la norme webfinger pourrait être une bonne solution. Mais je pense que cela pourrait aussi entrer en conflit avec l'e-mail git d'un utilisateur.

Où est le conflit ?

Au contraire, ce que je n'aime pas à propos de Webfinger, c'est qu'il a besoin de contrôler
la racine du domaine (que vous n'avez pas avec l'URL OpenID).

En ce qui concerne "quelle norme voulons-nous choisir", je veux juste vous indiquer ActivityPub qui est actuellement en cours de finalisation par le groupe de travail de la Fédération sociale du W3C. Certains projets l'implémentant (ou y travaillant actuellement) sont pump.io, Mastodon et MediaGoblin.

Cependant, ils n'utilisent pas WebFinger car ils n'aiment pas l'idée d'un chemin fixe .bien connu, mais il existe des idées sur l'interopérabilité .

Cette fonctionnalité changera vraiment la donne ; keybase.io est récemment sorti avec git crypté côté client, c'est aussi intéressant.

Je veux juste souligner que ActivityPub est maintenant terminé.

L'ajout de la prise en charge de l'AP rendrait Gitea compatible avec un nombre croissant de serveurs fédérés, tels que Mastodon, PeerTube, NextCloud et HubZilla, élargissant considérablement sa portée, sans parler d'un différenciateur hors pair par rapport à GitLab.
Cela aurait également le potentiel de détrôner GitHub en tant qu'hébergement incontournable pour les projets open source, car la plupart sont ici pour le flux de travail de demande d'extraction de la communauté qu'AP permettrait de manière décentralisée, augmentant la confidentialité et éliminant un point de défaillance unique pour un grand pourcentage de la communauté du logiciel libre.

Quoi qu'il en soit, j'espère que cela sera mis en œuvre, il a le potentiel d'être révolutionnaire !

Comme déjà indiqué dans le chat, ActivityPub in go est un PITA car il est difficile de le faire dans un langage statique comme go.

@tboerger Intéressant. La spécification ActivityPub est assez riche en héritage OO, mais cela devrait être possible de modéliser dans Go avec l'intégration de structures, mais pour autant que je sache, il n'y a rien comme serde dans Rust (https://docs.serde. rs/serde_json/value/index.html), ce qui simplifie beaucoup les choses, mais il y a quelques efforts pour implémenter ActivityPub dans Go, ce qui peut être un bon début car non seulement il implémente déjà l'analyse json-ld , mais aussi définit le vocabulaire de base pour ActivityStreams.

À quels désagréments spécifiques pensez-vous ici ?

@MatejLach Un autre projet https://github.com/go-fed/activity

Proposition pertinente dans le référentiel gogs :
https://github.com/gogs/gogs/issues/4437

Dans le dépôt de Gitlab :
https://gitlab.com/gitlab-org/gitlab-ee/issues/4517

Salut! Co-éditeur d'ActivityPub ici. Je suis assez occupé en ce moment mais j'aimerais que cela se produise... si vous avez besoin de questions, n'hésitez pas à me contacter par ping ou à demander dans #social sur irc.w3.org

N'hésitez pas à me contacter sur Mastodon pour toute question/préoccupation/commentaire concernant la bibliothèque https://github.com/go-fed/activity mentionnée par @jas99 . J'ai évidemment un intérêt direct dans le résultat de la décision, mais je serais heureux de fournir des informations franches sur mes expériences de travail dans l'intersection go + ActivityPub. Je suis d'accord avec @tboerger que la mise en œuvre d'ActivityPub dans go est une falaise abrupte.

Peut-être pourrions-nous créer un nouveau référentiel nommé index et configurer le nouveau domaine index.gitea.io pour faire cela ?

Pourquoi avons-nous besoin d'un serveur d'index ? @lunny

Ce serait génial si nous pouvions avoir différents projets discutant d'une implémentation commune du protocole ActivityPub (c'est-à-dire en utilisant la même extension pour les verbes, etc.). Cela permettrait aux utilisateurs de gitea, gogs et gitlab de travailler ensemble de manière transparente, tout comme les utilisateurs de diverses plateformes de médias sociaux qui se fédèrent peuvent discuter de manière transparente.

Serait-ce l'endroit? -> https://github.com/git-federation/gitpub

@jaywink super idée !

Ce serait incroyable ! Je pense que Nextcloud (/ Owncloud) est l'exemple parfait de la façon dont cela pourrait fonctionner avec l'implémentation idéale, comme @JonasFranzDEV l' a suggéré.

Avec Nextcloud, si je veux partager un dossier avec un utilisateur sur une autre instance, je peux facilement le faire et configurer un dossier partagé sur les deux instances.

Si je pouvais le faire pour un référentiel hébergé sur mon instance Gitea, en accordant à un utilisateur d'une autre instance fédérée l'accès au référentiel, ce référentiel apparaissant alors dans leur interface Gitea avec la pleine capacité d'interagir avec les problèmes, etc. (avec une dénotation claire dans le UI que ce référentiel était hébergé sur une autre instance), ce serait assez étonnant.

L'objectif en cours de discussion d'adopter une norme partagée entre Gitea et d'autres projets open source auto-hébergés (comme GitLab CE) a certainement du sens, et ce serait formidable si cela était adopté permettant une fédération entre Gitea, Gogs, GitLab, etc. Migrer depuis GitHub pour des projets privés est facile sans vraiment rien perdre, mais pour les projets open source publics, nous devons reconnaître qu'un grand avantage de GitHub est la communauté. J'ai découvert beaucoup de projets actuellement sur GitHub. S'il existait un moyen de fédérer les projets populaires, le flux d'activité des utilisateurs (c'est-à-dire pouvoir suivre un ami sur une autre instance et suivre son activité, les projets aimés, les paramètres de confidentialité pris en compte, etc.) serait excellent - si cela était possible.

Les demandes d'extraction fédérées seraient un excellent premier pas vers cela (#184), et probablement la fonctionnalité manquante la plus cruciale pour le moment.

11 mois depuis le dernier commentaire ici. Je me demande s'il y a encore des projets en cours ?

Quand il y a une sorte de norme convenue que oui

Les discussions en cours se déroulent dans le cadre du projet forgefed, alors suivez-les si vous voulez en savoir plus : https://github.com/forgefed/forgefed

Comme @lafriks l'a mentionné, une fois qu'il existe une norme convenue, divers projets peuvent la mettre en œuvre.

L'URL correcte pour le projet forgefed est maintenant https://notabug.org/peers/forgefed

Il semble que cela devrait être d'une importance primordiale maintenant, étant donné que github supprime maintenant les comptes de ppl de pays entiers.

ForgeFed dispose également d'un forum de discussion . Ce serait formidable d'impliquer quelqu'un de Gitea.

+1 pour ça. Travailler à partir d'une instance locale auto-hébergée mais ne pas être isolé en raison de ce choix serait vraiment le meilleur des deux mondes.

Le groupe de travail ForgeFed aurait désespérément besoin de développeurs des forges actuelles pour donner des commentaires : https://talk.feneas.org/t/working-group-instructions/196

J'aimerais juste ajouter qu'avant que Microsoft n'inspire une migration massive loin de Github, cela n'aurait pas été une fonctionnalité qui tue... MAINTENANT, ça l'est. De moins en moins de dépôts pour les projets de système d'exploitation que je recherche sont maintenant sur Github (PEUT-ÊTRE reflétés ici).

J'ai lu que l'historique des commits Github peut se lire comme un CV et que l'une des raisons pour lesquelles le monde du logiciel est si mobile au niveau de la carrière est qu'une personne peut auto-enseigner des compétences précieuses, les DÉMONTRER FACILEMENT (historique public de github), et donc se qualifier pour de meilleurs revenus / etc. Si votre historique de contribution est réparti sur des dizaines de serveurs privés, il est BEAUCOUP moins visible/utile.

De plus, n'importe lequel de ces serveurs peut tomber en panne à tout moment et cette partie de votre historique a maintenant disparu. Une implémentation correcte des référentiels fédérés signifierait que je pourrais participer à des dizaines de projets sur des dizaines d'instances (à partir de mon instance) et s'ils tombaient TOUS, j'aurais toujours mon "profil git fédéré".

Lien vers la feuille de route ForgeFed (il y a un financement pour ceux qui y travailleront):

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

Peut-être, pour une implémentation simple, gitea pourrait exécuter un nœud ipfs en arrière-plan hébergeant les fichiers du référentiel local (en utilisant ipns pour pointer vers les dernières versions des référentiels). Nous pourrions alors avoir une implémentation simple du protocole de potins pour trouver d'autres instances de gitea et obtenir des hachages ipns et des données préliminaires (étoiles, nom).
L'avantage d'utiliser ipfs serait que lorsque les utilisateurs d'une instance souhaitent afficher ou bifurquer des référentiels sur d'autres instances, cela contribuerait à héberger des parties de ce référentiel et accélérerait l'accès au référentiel pour le réseau dans son ensemble.

L'utilisation d'ipfs/ipns pourrait également être utilisée pour distribuer des données utilisateur telles que des référentiels étoilés, des demandes d'extraction, des biographies, etc. données de profil pour les utilisateurs inconnus.

ipfs a déjà une implémentation go et par exemple la découverte quelque chose comme ça pourrait être utilisé.

Il n'y a aucune exigence de stockage peer-to-peer ici, ce que vous décrivez ne semble pas nécessaire ni même lié au problème en question. Je ne pense pas qu'il y ait intérêt à s'éloigner du format de stockage et du protocole de transfert Git. Peut-être devriez-vous ouvrir un problème séparé si vous voyez un avantage ici (ce n'est certainement pas le cas).

Il n'y a aucune exigence pour le stockage peer-to-peer ici

Je pense que gitea bénéficierait grandement du partage peer-to-peer des référentiels afin que les référentiels populaires soient redondants en cas de panne d'instances. Alors que quelqu'un peut simplement mettre en miroir un référentiel sur sa propre instance, cela fragmenterait le développement d'un projet s'il n'y avait pas d'endroit central où s'engager. Si le protocole git était superposé sur IPFS, il permettrait la déduplication lors de la création de projets sur une seule instance (afin qu'une copie entière n'ait pas à être stockée).

ce que vous décrivez ne semble pas nécessaire ni même lié au problème en question.

La raison pour laquelle la fédération est si utile (et pourquoi les gens la veulent tant) est qu'elle permet la collaboration entre les instances. Le système de noms interplanétaire (IPNS) a un comportement identique à OpenID car il peut être utilisé pour identifier un utilisateur qui a la permission de mettre à jour certaines données (par exemple, ses référentiels et son profil personnel). Une adresse IPNS pourrait identifier de manière unique un utilisateur d'une autre instance sans nécessairement avoir à lier cet utilisateur à une instance spécifique. Donnons un exemple :
Alice héberge elle-même une instance de gitea sur aliceland.net
Lorsqu'Alice crée un nouveau compte, gitea crée un profil vide, l'héberge sur IPFS, puis génère une adresse IPNS unique qui pointe vers ce profil. Chaque fois qu'Alice crée un nouveau référentiel ou met à jour son profil de quelque manière que ce soit, gitea créera (en coulisses) un nouvel enregistrement IPFS, détachera l'ancien et lui réattribuera l'adresse IPNS d'Alice.
Supposons maintenant que Bob veuille soumettre une demande de fusion depuis son miroir du référentiel sur bobland.net vers aliceland.net.
Lorsque Bob a initialement forké le dépôt d'Alice sur bobland.net, il a noté l'IPNS du dépôt d'Alice ainsi que l'emplacement IPFS du commit à partir duquel il a forké.
Lorsque Bob veut ouvrir une demande de fusion, il écrit son message, puis bobland.net placera les éléments suivants dans un bloc IPFS :

• Adresse d'utilisateur IPNS de Bob
• L'adresse IPFS des commits que Bob veut récupérer
• L'adresse IPFS du commit dans le dépôt d'Alice qui doit être modifiée
• Message et titre de Bob pour la demande de fusion
• Signature des données avec la clé de profil IPNS privée de Bob

Bobland.net enverra alors l'adresse IPFS à aliceland.net qui pourra alors choisir de l'ignorer totalement, OU analyser l'adresse, vérifier les commits, créer une adresse IPNS pour le fil de commentaires (qui pointe vers tous les commentaires) puis notifier Alice qu'un type nommé Bob sur l'instance Bobland.net a envoyé une demande de fusion pour 3 commits sur IPFS. Les commentaires seraient également hébergés sur IPFS et accessibles via une adresse IPNS.
Ce modèle d'utilisation d'IPNS pour les données modifiables (comme un fil de commentaires) et d'IPFS pour les données immuables (comme les commentaires et les validations) peut être appliqué pour la plupart des fédérations inter-instances.

Je ne pense pas qu'il y ait intérêt à s'éloigner du format de stockage et du protocole de transfert Git.

Cette approche de la fédération n'aurait pas à s'éloigner du format Git. Git peut simplement être superposé et stocké sur ifps (tout en profitant également de la déduplication). Le système Merkle Tree de Git ne doit pas nécessairement être intégré à IPFS (bien que ce serait cool) et le protocole de transfert git serait toujours le même, IPFS modérerait simplement la communication entre les instances.

Pouvez-vous simplement ouvrir un problème séparé ? Celui-ci concerne quelque chose de spécifique, et ForgeFed travaille déjà sur un protocole. Mieux encore, parlez-en avec eux.

S'empiler sur des problèmes avec des commentaires comme "qu'en est-il d'ipfs/filecoin/blockchain" semble tout simplement impoli.

+1

GitLab discute également de cette fonctionnalité : https://gitlab.com/gitlab-org/gitlab/-/issues/6468

J'ai envoyé un ping sur la discorde de développement de gitea il y a quelques jours en tant que FYI, et j'ai essayé de manière proactive de contacter certaines des personnes derrière ForgeFed, car avec go-fed v1 en cours et documenté, ce serait bien d'obtenir une instance de gitea fédéré sur ActivityPub bien que ce ne soit pas une mince affaire. Je pense que les gens de Gitea sont occupés avec d'autres priorités atm. Malheureusement, je n'ai pas réussi à joindre les gens de ForgeFed. :(

Certains d'entre nous dans la communauté ActivityPub, sortant d'APConf2020, expérimentent un processus de documentation léger de base sur une instance gitea et cela fait bizarre de ne pas encore pouvoir se fédérer avec.

Git possède déjà toutes les fonctionnalités nécessaires à la mise en miroir décentralisée, la seule fonctionnalité manquante est ce qui est nécessaire pour le coordonner, ce qui est exactement ce que fait ForgeFed. IPFS n'a pas besoin d'être ici, et compte tenu de la catastrophe de leur lancement sur le réseau principal, je ne suis pas sûr qu'il soit sûr de se lier profondément à d'autres projets de Protocol Labs.

Je suis intéressé à collaborer sur l'une des initiatives existantes. Essayons de constituer un groupe de travail. Peut suggérer ce canal Matrix pour une discussion plus approfondie #n oteworthy:tincan.community