Gitea: 組織、リポジトリ、ユーザーのためのフェデレーション

フェデレーションリポジトリをサポートするのにおそらく十分でしょう

@kolaenteフェデレーション機能は、ユーザーが明確に理解できるようにします。 リポジトリを共有したい場合は、ミラー機能を使用する必要があります。 ただし、プロジェクトマネージャーが他のgitインスタンスからユーザーを追加するのは非常に便利です。

＃184も参照してください（これはその複製ですか？）

@strkのようなものですが、これはさらに進んでいると思います

@strk種類。 ただし、この問題には、プルリクエストだけでなく、組織向けのフェデレーション機能の完全な統合が含まれています。

リモートユーザーの承認を意味しますか？
私が思うに、「フェデレーション」を多くの異なる小さなものに分割することは有用だと思います
実装するもの、または単一のチケットが大きくなりすぎるでしょう。

@strk私はこれを多くのチケットに分割するという考えに同意します。 このチケットはユーザーフェデレーションチケットかもしれませんね。 しかし、他のプラットフォームのユーザーの認証は必要ありません。 他のユーザーを追加できるようにしたい。 ユーザーは、ユーザーのGiteaインスタンスから招待状を受け取ります。 彼は自分のインスタンスからリポジトリまたは組織にアクセスします。

フェデレーション内の誰かに権限を付与するには、次のことができる必要があります
その誰か（グローバルアドレス）を識別します。 あなたがowncloudについて述べたように私は
owncloudは「@「識別子として、しかし私は何を知らない
そのために使用するプロトコル。 Friendica / GNUSocialおよびその他のOStatusの実装
連盟は「@"他の何かへのマッピング
Webfinger標準（異なる指定を可能にするために開かれています
プロトコル）。 別のコミュニティ（IndieWebコミュニティ、indieweb.orgを参照）は
バージョン2.0までのOpenIDで使用されるため、人を識別するためのWebアドレス。
新しいOpenID（OpenID-Connect）は再びWebfingerを使用します。

webfinger標準は良い解決策かもしれないと思います。 しかし、それはユーザーのgitメールとも競合する可能性があると思います。

対立はどこにありますか？

むしろ、私がWebfingerについて嫌いなのは、それを制御する必要があるということです。
ドメインルート（OpenID URLにはありません）。

「どの標準を選択したいのか」については、W3CのSocialFederationワーキンググループによって現在完成されているActivityPubを紹介したいと思います。 それを実装している（または現在取り組んでいる）プロジェクトには、pump.io、Mastodon、MediaGoblinがあります。

彼らは固定された.well-knownパスのアイデアを嫌うので、WebFingerを使用しませんが、相互運用性についてのアイデアがあります。

この機能は本当にゲームチェンジャーになります。 keybase.ioは最近、クライアント側で暗号化されたgitをリリースしましたが、これも興味深いことです。

ActivityPubが完了したことを指摘したいだけです。

APのサポートを追加すると、Giteaは、Mastodon、PeerTube、NextCloud、HubZillaなど、ますます多くのフェデレーションサーバーと互換性があり、GitLabに対する際立った差別化要因は言うまでもなく、その範囲が大幅に広がります。
また、GitHubをオープンソースプロジェクトの頼りになるホスティングとして廃止する可能性もあります。これは、APが分散化された方法で許可するコミュニティプルリクエストワークフローのためにほとんどがここにあり、プライバシーを向上させ、単一障害点を排除するためです。自由ソフトウェアコミュニティの大部分。

とにかく、これが実装されることを願っています。革命的な可能性があります。

チャットですでに述べたように、goのような静的な言語で行うのは難しいため、goのActivityPubはPITAです。

@tboerger興味深い。 ActivityPubの仕様は非常に継承が多いOOですが、構造体埋め込みを使用してGoでモデル化できるはずですが、私が知る限り、Rust（https：//docs.serde）にはserdeのようなものはありません。 rs / serde_json / value / index.html）、これは物事をかなり単純化しますが、GoでActivityPubを実装するための努力があります。これは、すでにjson-ld解析を実装しているだけでなく、 ActivityStreamsのコアボキャブラリーを定義します。

ここでどのような具体的な迷惑を考えていますか？

@MatejLach別のプロジェクトhttps://github.com/go-fed/activity

gogsリポジトリの関連する提案：
https://github.com/gogs/gogs/issues/4437

Gitlabのリポジトリ：
https://gitlab.com/gitlab-org/gitlab-ee/issues/4517

こんにちは！ ActivityPubの共同編集者はこちら。 私は現在かなり忙しいですが、これが起こるのを見たいです...質問が必要な場合は、遠慮なく私にpingするか、irc.w3.orgの#socialで質問してください。

@ jas99が言及したhttps://github.com/go-fed/activityライブラリに関する質問/懸念/コメントについては、マストドンで私に連絡することを躊躇しないでください。 私は明らかに決定の結果に既得権を持っていますが、go + ActivityPub交差点で働いた私の経験について率直な情報を提供したいと思います。 @tboergerに同意します。これは、ActivityPubをgoに実装することは急な崖です。

たぶん、 indexという名前の新しいリポジトリを作成し、それを行うために新しいドメインindex.gitea.ioを設定できますか？

なぜインデックスサーバーが必要なのですか？ @lunny

ActivityPubプロトコルの一般的な実装について議論するさまざまなプロジェクトがあれば素晴らしいでしょう（つまり、動詞に同じ拡張機能を使用するなど）。 これにより、連邦政府がシームレスに話し合うことができるさまざまなソーシャルメディアプラットフォームのユーザーと同じように、gitea、gogs、およびgitlabのユーザーがシームレスに連携できるようになります。

ここはその場所でしょうか？ -> https://github.com/git-federation/gitpub

@jaywink素晴らしいアイデア！

これはすごいでしょう！ @JonasFranzDEVが示唆したように、Nextcloud（/ Owncloud）は、これが理想的な実装でどのように機能するかを示す完璧な例だと思います。

Nextcloudを使用すると、別のインスタンスのユーザーとフォルダーを共有したい場合、簡単に共有して、両方のインスタンスに共有フォルダーを設定できます。

Giteaインスタンスでホストされているリポジトリに対してそれを行うことができれば、別のフェデレーションインスタンスのユーザーにリポジトリへのアクセスを許可すると、そのリポジトリがGiteaインターフェースに表示され、問題などと対話する完全な機能が提供されます（このリポジトリが別のインスタンスでホストされていたUI）、それはかなり驚くべきことです。

Giteaと他のオープンソースのセルフホストプロジェクト（GitLab CEなど）との間で共有標準を採用するという目標は間違いなく理にかなっています。これが採用され、Gitea、Gogs、GitLabなどの間のフェデレーションが可能になるとよいでしょう。プライベートプロジェクトへのGitHubからの移行は簡単で、何も失われることはありませんが、パブリックオープンソースプロジェクトの場合、GitHubの大きなメリットはコミュニティであることを認める必要があります。 実際にGitHubでたくさんのプロジェクトを発見しました。 人気のあるプロジェクトを統合する方法があれば、ユーザーのアクティビティフィード（つまり、別のインスタンスで友達をフォローし、プライバシー設定を考慮して、彼らのアクティビティ、いいねしたプロジェクトをフォローできるなど）は優れています-それが可能であれば。

フェデレーションプルリクエストは、これに向けた優れた最初のステップ（＃184）であり、現時点で最も重要な欠落している機能である可能性があります。

ここでの最後のコメントから11ヶ月..まだ計画があるのだろうか？

はいよりも合意されたある種の基準がある場合

現在の議論は偽造プロジェクトの一環として行われているため、詳細を知りたい場合は、 https ：//github.com/forgefed/forgefedをフォローしてください。

@lafriksが述べたように、合意された標準があれば、さまざまなプロジェクトでそれを実装できます。

偽造されたプロジェクトの正しいURLはhttps://notabug.org/peers/forgefedになりました

githubが国全体からpplのアカウントを削除していることを考えると、このようなことが今最も重要であるように思われます。

ForgeFedには、ディスカッションフォーラムもあります。 Giteaの誰かを巻き込むのは素晴らしいことです。

このために+1。 ローカルのセルフホストインスタンスから作業しますが、その選択のために分離されていないことは、両方の世界で本当に最善です。

ForgeFedワーキンググループは、コメントを提供するために現在のフォージの開発者を必死に必要とします： https ：//talk.feneas.org/t/working-group-instructions/196

マイクロソフトがGithubからの大規模な移行を促す前は、これはキラー機能ではなかったでしょう...今はそうです。 私が調査しているOSプロジェクトのリポジトリは、現在Githubにあります（ここにミラーリングされている可能性があります）。

Githubのコミット履歴は履歴書のように読み取ることができ、ソフトウェアの世界が非常にモバイルである理由の1つは、人が貴重なスキルを自己学習し、それらを簡単にデモンストレーションできることです（公開されたgithubの履歴）。より良い収益などの資格を得る。 あなたの貢献履歴が数十のプライベートサーバーに分散している場合、それははるかに目立たない/有用ではありません。

また、これらのサーバーはいつでもダウンする可能性があり、履歴のその部分は失われます。 フェデレーションリポジトリの適切な実装は、（私のインスタンスからの）数十のインスタンスで数十のプロジェクトに参加できることを意味し、それらがすべてダウンした場合でも、「フェデレーションgitプロファイル」を保持します。

ForgeFedロードマップへのリンク（それに取り組む人々のための資金があります）：

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

おそらく、単純な実装の場合、giteaはローカルリポジトリファイルをホストするバックグラウンドでipfsノードを実行できます（ ipnsを使用してリポジトリの最新バージョンをポイントします）。 次に、他のgiteaインスタンスを検索し、ipnsハッシュと予備データ（星、名前）を取得するための簡単なゴシッププロトコルの実装を行うことができます。
ipfsを使用する利点は、あるインスタンスのユーザーが他のインスタンスのリポジトリを表示またはフォークしたい場合に、そのリポジトリの一部をホストし、ネットワーク全体でリポジトリへのアクセスを高速化することに貢献することです。

ipfs / ipnsの使用は、スター付きリポジトリ、プルリクエスト、略歴などのユーザーデータの配布にも使用できます。各ノードは、インスタンスが関心を持っている他のネットワーク上のユーザーの名前とipnsハッシュのみを保存し、リクエストするのは簡単です。不明なユーザーのプロファイルデータ。

ipfsにはすでにgo実装があり、たとえば、このようなディスカバリーを使用できます。

ここではピアツーピアストレージの要件はありません。あなたが説明することは必須ではなく、目前の問題に関連しているようにも見えません。 Gitストレージフォーマットと転送プロトコルから離れることには関心がないと思います。 ここでメリットが見られる場合は、別の問題を開く必要があるかもしれません（私は確かにそうしません）。

ここではピアツーピアストレージの要件はありません

giteaは、リポジトリをピアツーピアで共有することで大きなメリットが得られると思います。これにより、インスタンスがダウンした場合に人気のあるリポジトリが冗長になります。 誰かがリポジトリを自分のインスタンスにミラーリングすることはできますが、コミットする中心的な場所がない場合は、プロジェクトの開発が断片化されます。 gitプロトコルがIPFSで階層化されている場合、単一のインスタンスでプロジェクトをフォークするときに重複排除が可能になります（したがって、コピー全体を保存する必要はありません）。

あなたが説明することは、必要ではないようであり、目前の問題に関連しているようにも見えません。

フェデレーションが非常に役立つ理由（および人々がそれを非常に望んでいる理由）は、インスタンス間のコラボレーションを可能にするためです。 InterPlanetary Name System（IPNS）は、特定のデータ（リポジトリや個人プロファイルなど）を更新する権限を持つユーザーを識別するために使用できるため、OpenIDと同じ動作をします。 IPNSアドレスは、必ずしもそのユーザーを特定のインスタンスに結び付ける必要なしに、別のインスタンスからユーザーを一意に識別できます。 例を挙げましょう：
アリスはaliceland.netでgiteaのインスタンスをセルフホスティングしています
アリスが新しいアカウントを作成すると、giteaは空のプロファイルを作成し、それをIPFSでホストしてから、そのプロファイルを指す一意のIPNSアドレスを生成します。 アリスが新しいリポジトリを作成したり、何らかの方法でプロファイルを更新したりするたびに、giteaは（舞台裏で）新しいIPFSレコードを作成し、古いレコードの固定を解除して、アリスのIPNSアドレスをそれに再割り当てします。
ここで、ボブがbobland.netのリポジトリのミラーからaliceland.netにマージ要求を送信したいとします。
ボブが最初にアリスのレポジトリをbobland.netにフォークしたとき、彼はアリスのレポジトリのIPNSと、フォークしたコミットのIPFSの場所をメモしました。
ボブがマージ要求を開きたいとき、彼は彼のメッセージを書き、それからbobland.netはIPFSブロックに次のものを入れます：

• ボブのIPNSユーザーアドレス
• ボブがプルしたいコミットのIPFSアドレス
• 変更する必要があるアリスのリポジトリ内のコミットのIPFSアドレス
• マージリクエストのボブのメッセージとタイトル
• ボブの秘密IPNSプロファイルキーを使用したデータの署名

次に、Bobland.netはIPFSアドレスをaliceland.netに送信します。これにより、IPFSアドレスを完全に無視するか、アドレスを解析してコミットを検証し、コメントスレッド（すべてのコメントを指す）のIPNSアドレスを作成して通知することができます。インスタンスBobland.netでBobという名前の人が、IPFSを介して3つのコミットのマージ要求を送信したというアリス。 コメントはIPFSを介してホストされ、IPNSアドレスを介してアクセスできます。
可変データ（コメントスレッドなど）にIPNSを使用し、不変データ（コメントやコミットなど）にIPFSを使用するこのパターンは、ほとんどのインスタンス間フェデレーションに適用できます。

Gitストレージフォーマットと転送プロトコルから離れることには関心がないと思います。

フェデレーションへのこのアプローチは、Git形式から離れる必要はありません。 Gitは、単純に階層化してifpsに保存できます（重複排除も利用できます）。 GitのMerkleTreeシステムは必ずしもIPFSと統合する必要はありません（それはクールですが）。Git転送プロトコルは同じですが、IPFSはインスタンス間の通信を緩和するだけです。

別の問題を開くことはできますか？ これは特定のものに関するものであり、ForgeFedはすでにプロトコルに取り組んでいます。 さらに良いことに、彼らと一緒にそれを持ち出してください。

「ipfs / filecoin / blockchainはどうですか」などのコメントで問題を積み上げるのは、失礼に思えます。

+1

GitLabもこの機能について議論しています： https ：//gitlab.com/gitlab-org/gitlab/-/issues/6468

私は数日前にFYIとしてgiteadevの不和にpingを送信し、Go-fed v1が実行されて文書化されているように、ForgeFedの背後にいる何人かの人々に積極的に連絡しようとしています。それは小さな努力ではありませんが、ActivityPubでフェデレーションされたgiteaの。 私はgiteaの人々が他の優先順位のATMで忙しいと思います。 残念ながら、私はForgeFedの人々を捕まえることに成功していません。 :(

APConf2020からリリースされたActivityPubコミュニティの一部は、giteaインスタンスで草の根の軽量ドキュメントプロセスを実験しており、まだそれと連携できないのは奇妙に感じます。

Gitには、分散型ミラーリングに必要なすべての機能がすでに備わっています。不足している機能は、Gitを調整するために必要な機能だけです。これは、まさにForgeFedが行うことです。 IPFSはここにある必要はなく、メインネットの立ち上げがどれほど悲惨なものであったかを考えると、ProtocolLabsによる他のプロジェクトと深く結びつくことが安全かどうかはわかりません。

既存のイニシアチブのいずれかに協力することに興味があります。 ワーキンググループをまとめてみましょう。 さらなる議論のためにこのマトリックスチャネルを提案できます#noteworthy：tincan.community