Gitea: 组织、存储库和用户的联合

支持联合存储库可能就足够了

@kolaente联合功能明确地为用户提供意义。 如果要共享存储库，则应使用镜像功能。 但是对于项目经理来说，从其他 git 实例中添加用户会非常方便。

另见 #184 （这是重复的吗？）

@strk有点像，但我认为这个更进一步

@strk有点。 但是这个问题包括对组织的联合功能的完全集成，而不仅仅是针对拉取请求。

你的意思是远程用户的授权？
因为我认为将“联邦”拆分为许多不同的小
要实施的事情，否则单张票会变得太大。

@strk我同意将这个东西分成许多票的想法。 这张票可能是用户联盟票不是吗？ 但我不想对其他平台的用户进行身份验证。 我希望能够添加其他用户。 用户将收到来自用户的 Gitea 实例的邀请。 他将从他的实例访问存储库或组织。

向联盟中的某人授予权限需要能够
识别某人（全球地址）。 正如你提到 owncloud 我
认为owncloud使用“@" 作为标识符，但我不知道是什么
它使用的协议。 Friendica/GNUSocial 和其他 OStatus 实施
联合会也可以使用“@" 通过映射到其他东西
Webfinger 标准（它是开放的，允许指定不同的
协议）。 另一个社区（IndieWeb 社区，参见 indieweb.org）使用
用于识别人员的网址，因为它与最高版本 2.0 的 OpenID 一起使用。
新的 OpenID (OpenID-Connect) 再次使用 Webfinger。

我认为 webfinger 标准可能是一个很好的解决方案。 但我认为它也可能与用户的 git 电子邮件冲突。

哪里有冲突？

相反，我不喜欢 Webfinger 的地方在于它需要控制
域根（OpenID URL 没有）。

关于“我们要选择什么标准”，我只想向您指出目前由 W3C 社会联合会工作组完成的ActivityPub 。 一些实现它的项目（或目前正在开发）是 pump.io、Mastodon 和 MediaGoblin。

他们不使用 WebFinger，因为他们不喜欢固定的 .well-known 路径的想法，但是有关于互操作性的想法。

此功能将真正改变游戏规则； keybase.io 最近推出了客户端加密 git，这也很有趣。

只想指出ActivityPub现在已经完成。

添加对 AP 的支持将使 Gitea 与越来越多的联合服务器兼容，例如 Mastodon、PeerTube、NextCloud 和 HubZilla，从而大大扩大了其覆盖范围，更不用说与 GitLab 的显着差异化了。
它也有可能取代 GitHub 作为开源项目的首选托管平台，因为大多数人都是为了社区拉取请求工作流程，AP 将以去中心化的方式允许，增加隐私并消除单点故障很大比例的自由软件社区。

无论如何，我希望这能得到实施，它有可能成为革命性的！

正如在聊天中已经说明的那样，Go 中的 ActivityPub 是一个 PITA，因为在 Go 这样的静态语言中很难做到。

@tboerger有趣。 ActivityPub 规范是非常重继承的 OO，但是应该可以使用结构嵌入在 Go 中建模，但是据我所知，Rust 中没有serde （https://docs.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 联合编辑在这里。 我现在很忙，但我希望看到这种情况发生……如果您需要问题，请随时联系我，或在 irc.w3.org 上的#social 中提问

如果有任何关于@jas99提到的https://github.com/go-fed/activity库的问题/疑虑/评论，请随时在 Mastodon 上与我联系。 我显然对决定的结果有既得利益，但很乐意提供有关我在 go+ActivityPub 交叉点工作的经历的坦率信息。 我同意@tboerger的观点，即在 go 中实现 ActivityPub 是一个陡峭的悬崖。

也许我们可以创建一个名为index的新存储库并设置新的域 index.gitea.io 来做到这一点？

为什么我们需要索引服务器？ @lunny

如果我们可以有不同的项目来讨论 ActivityPub 协议的通用实现（即对动词使用相同的扩展名等），那将是很棒的。 这将使 gitea、gogs 和 gitlab 的用户能够无缝协作，就像联盟可以无缝讨论的各种社交媒体平台的用户一样。

会是这个地方吗？ -> https://github.com/git-federation/gitpub

@jaywink好主意！

这将是惊人的！ 正如@JonasFranzDEV 所建议的那样，我认为 Nextcloud (/Owncloud) 是一个完美的例子，说明了它如何与理想的实现一起工作。

使用 Nextcloud，如果我想与另一个实例上的用户共享一个文件夹，我可以轻松地做到这一点，并在两个实例之间设置一个共享文件夹。

如果我可以对托管在我的 Gitea 实例上的存储库执行此操作，则授予另一个联合实例上的用户访问该存储库的权限，然后该存储库将出现在他们的 Gitea 界面中，并具有与问题等交互的全部能力（在这个 repo 托管在另一个实例上的 UI），那将是非常惊人的。

正在讨论的目标是在 Gitea 和其他开源自托管项目（例如 GitLab CE）之间采用共享标准绝对是有道理的，如果采用允许 Gitea、Gogs、GitLab 等之间的联合，那就太好了。从 GitHub 迁移到私人项目很容易，没有任何损失，但对于公共开源项目，我们需要承认 GitHub 的一大好处是社区。 我实际上在 GitHub 上发现了很多项目。 如果有某种方法可以联合受欢迎的项目，那么用户活动源（即能够在另一个实例上关注朋友并关注他们的活动、喜欢的项目、考虑到隐私设置等）将会非常好——如果可能的话。

联合拉取请求将是朝着这一目标迈出的重要的第一步（#184），并且可能是目前最关键的缺失功能。

距离上次在这里发表评论已有 11 个月了。我想知道是否还有计划？

当有某种标准达成一致时

当前的讨论是作为 forgefed 项目的一部分进行的，因此如果您想了解更多信息，请继续关注： https ://github.com/forgefed/forgefed

正如@lafriks 所提到的，一旦有一个商定的标准，那么各种项目都可以实施它。

forgefed 项目的正确 URL 现在是https://notabug.org/peers/forgefed

考虑到 github 现在正在从整个国家/地区删除 ppl 帐户，现在看来这应该是最重要的。

ForgeFed 现在也有一个讨论论坛。 让Gitea的人参与进来会很棒。

为此+1。 从本地自托管实例工作，但不会因为这种选择而被隔离，这确实是两全其美。

ForgeFed工作组迫切需要当前锻造的开发人员发表评论： https ://talk.feneas.org/t/working-group-instructions/196

我想补充一点，在微软激发从 Github 大规模迁移之前，这不会是一个杀手级功能......现在它是。 我正在研究的操作系统项目的存储库现在在 Github 上越来越少（可能在此处反映）。

我读过 Github 提交历史可以读起来像简历，软件世界如此具有职业移动性的原因之一是人们可以自学有价值的技能，轻松展示它们（公共 github 历史），因此有资格获得更好的收入/等。 如果您的贡献历史分布在数十个私人服务器上，那么它的可见性/有用性就会大大降低。

此外，这些服务器中的任何一个都可能随时关闭，您的那部分历史记录现在已经消失了。 联合存储库的正确实现意味着我可以参与几十个实例（来自我的实例）上的几十个项目，如果它们都失败了，我仍然有我的“联合 git 配置文件”。

链接到 ForgeFed 路线图（为那些将要工作的人提供资金）：

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

也许，对于一个简单的实现，gitea 可以在后台运行一个ipfs节点来托管本地存储库文件（使用ipns指向最新版本的存储库）。 然后我们可以有一个简单的gossip协议实现来查找其他 gitea 实例并获取 ipns 哈希和初步数据（星号、名称）。
使用 ipfs 的好处是，当一个实例上的用户想要查看或复制其他实例上的存储库时，它将有助于托管该存储库的部分内容，并使整个网络更快地访问存储库。

使用 ipfs/ipns 还可以用于分发用户数据，例如已加星标的存储库、拉取请求、生物等。每个节点只会为实例关心的其他网络上的用户存储名称和 ipns 哈希，并且请求将是微不足道的未知用户的个人资料数据。

ipfs 已经有一个 go实现，例如可以使用这样的发现。

这里不需要对等存储，您所描述的似乎不需要，甚至与手头的问题无关。 我不认为有兴趣摆脱 Git 存储格式和传输协议。 如果您在这里看到好处，也许您应该打开一个单独的问题（我当然没有）。

这里不需要点对点存储

我认为 gitea 将从存储库的点对点共享中受益匪浅，因此在实例下降的情况下流行的存储库将是多余的。 虽然有人可以将存储库镜像到他们自己的实例，但如果没有中心位置可以提交，它会分散项目的开发。 如果 git 协议在 IPFS 上分层，则在单个实例上 fork 项目时将允许重复数据删除（因此不必存储整个副本）。

您所描述的似乎不需要，甚至与手头的问题无关。

联合如此有用的原因（以及人们如此需要它的原因）是它允许跨实例协作。 星际名称系统 (IPNS) 与 OpenID 具有相同的行为，因为它可用于识别有权更新某些数据（例如，他们的存储库和个人资料）的用户。 IPNS 地址可以唯一地标识来自另一个实例的用户，而不必将该用户绑定到特定实例。 举个例子：
Alice 在 aliceland.net 上自托管了一个 gitea 实例
当 Alice 创建一个新帐户时，gitea 将创建一个空配置文件，将其托管在 IPFS 上，然后生成一个指向该配置文件的唯一 IPNS 地址。 每当 Alice 创建一个新的存储库或以任何方式更新她的个人资料时，gitea 将（在幕后）创建一个新的 IPFS 记录，取消固定旧记录，并重新分配 Alice 的 IPNS 地址给它。
现在假设 Bob 想要从 bobland.net 上的存储库镜像向 aliceland.net 提交合并请求。
当 Bob 最初将 Alice 的 repo 分叉到 bobland.net 时，他记下了 Alice 的 repo 的 IPNS 以及他分叉的提交的 IPFS 位置。
当 Bob 想要打开一个合并请求时，他会写下他的消息，然后 bobland.net 会将以下内容放入 IPFS 块中：

• Bob 的 IPNS 用户地址
• Bob 想要拉入的提交的 IPFS 地址
• Alice 的 repo 中应修改的提交的 IPFS 地址
• Bob 的合并请求的消息和标题
• 使用 Bob 的私有 IPNS 配置文件密钥对数据进行签名

Bobland.net 然后将 IPFS 地址发送到 aliceland.net，然后它可以选择完全忽略它，或者解析地址，验证提交，为评论线程（指向所有评论）创建一个 IPNS 地址，然后通知爱丽丝，在 Bobland.net 实例上名为 Bob 的某个人已经通过 IPFS 发送了 3 次提交的合并请求。 评论也将托管在 IPFS 上，并可通过 IPNS 地址访问。
这种将 IPNS 用于可变数据（如评论线程）和 IPFS 用于不可变数据（如评论和提交）的模式可以应用于大多数实例间联合。

我不认为有兴趣摆脱 Git 存储格式和传输协议。

这种联合方法不必脱离 Git 格式。 Git 可以简单地分层并存储在 ifps 上（同时还可以利用重复数据删除）。 Git 的 Merkle Tree 系统不一定必须与 IPFS 集成（尽管那会很酷），并且 git 传输协议仍然是相同的，IPFS 只会调节实例之间的通信。

你可以单独打开一个问题吗？ 这是一个特定的东西，ForgeFed 已经在制定一个协议。 更好的是，与他们一起提出。

用诸如“ipfs/filecoin/blockchain 怎么样”之类的评论来讨论问题似乎很粗鲁。

+1

GitLab 也在讨论这个功能： https ://gitlab.com/gitlab-org/gitlab/-/issues/6468

几天前，我作为一个 FYI 对 gitea dev discord 进行了 ping 操作，并且一直在积极尝试联系 ForgeFed 背后的一些人，因为 go-fed v1 已经完成并记录了它会很高兴获得一个实例在 ActivityPub 上联合的 gitea 尽管这是一个不小的努力。 我认为 gitea 人正忙于其他优先事项。 不幸的是，我没有成功联系到任何 ForgeFed 人员。 :(

我们在 ActivityPub 社区中的一些人，从 APConf2020 开始，正在尝试在 gitea 实例上建立一个草根轻量级文档流程，但还不能与之联合感觉很奇怪。

Git 已经具备去中心化镜像所需的所有功能，唯一缺少的功能是协调它所必需的功能，而这正是 ForgeFed 所做的。 IPFS 没有必要在这里，考虑到他们的主网启动是多么灾难性，我不确定与 Protocol Labs 的其他项目紧密联系是否安全。

我有兴趣就现有的任何举措进行合作。 让我们尝试组建一个工作组。 可以推荐这个 Matrix 频道以供进一步讨论#noteworthy:tincan.community