ActivityPub 支持：第一阶段 RFC

贡献 功能
1

继续自 Federation support for Discourse - #21 by rishabh, Tools to "aggregate" many Discourse forums? - #27 by Falco 和 ActivityPub Implementation for Discourse

为什么需要？

许多 Discourse 用户面临的一个常见问题是，无法展示他们所订阅的所有兴趣小组的聚合内容。目前，没有一种简便的方式可以从多个 Discourse 实例中获取内容，并将其整合为一个集中且社交化的用户信息流。像 Reddit 这样的中心化平台通过为所有社区提供单一登录入口，并在 reddit.com 首页展示所有社区的聚合信息流来解决这一问题。我们希望通过 ActivityPub 协议，在 Discourse 中复现这一功能。

例如，用户 A 经常访问多个 Discourse 实例：一个用于政治讨论，两个用于爱好交流，还有一个用于本地社区论坛，但却无法在一个统一的信息流中获取所有相关内容。相比之下，如果你加入了多个 Facebook 群组或 Reddit 子版块，最相关的帖子会直接出现在你的信息流中。

规范（v1）

我们可以通过 Discourse 插件实现以下功能，来构建一个最小可行产品（MVP）原型：

  1. 按需生成 ActivityPub 信息流（针对每个已有 RSS 信息流的页面）

    • 类似于在 URL 后添加 .rss，这将允许通过请求正确的端点，使用 AP 协议获取内容。

    • 我们甚至可能通过向 URL 附加用户 API 密钥，为私有内容启用此功能。

  1. 让论坛管理员按类别启用 ActivityPub（出站），还是默认全部启用？
    (我认为 @Falco 对此有一些想法)

  2. 找到一种方法，在 Discourse 论坛或 Mastodon 信息流中消费这些内容（入站）

下一步

我们肯定需要从小处着手，因此首先需要确定一组小而可行的功能，作为第一版迭代的内容。我一直在研究 ActivityPub 协议，但对其内部运作机制还不够熟悉。因此，我邀请其他对此表现出浓厚兴趣的参与者（@Falco, @hellekin, @merefield）加入讨论，帮助我们为第一版迭代制定可行的规范，并对上述规范提出修改建议。

资源

39 个赞
Community has no boundary: Discourse-as-a-Fabric - ideation & brainstorm
Matrix protocol for chat
Community has no boundary: Discourse-as-a-Fabric - ideation & brainstorm
2

以下是来自旧话题的一些亮点：:arrow_down:

同意，我认为这正是 @Falco 提出的 v1 版本的运作方式。

6 个赞
3

非常棒的举措，谢谢。

我想先说：我们是否应该最初专注于“做什么”，而不是“怎么做”？技术架构可以稍后考虑？我之所以这么说，是因为如果过早确定技术架构，可能会限制功能。

我希望在版本 1 中能看到“发现的发现”列表，首先包括：

  • “最新”列表，展示来自各来源的每个最新主题的预览（即所有来源“最新”列表的简单合并）
  • “关注”列表，展示您选择接收通知的每个有活动的主题的预览。（这一设计借鉴了现有移动应用的思路——将关注主题上新活动的通知直接扩展为对底层主题预览本身的展示）。
9 个赞
5

感谢你的开启这个话题！

我必须说，最初涉及 Facebook 类比的提案超出了我的理解范围：我对 Facebook 的功能一无所知，也不明白它与 Discourse 有任何关联。

我对 Discourse 支持 ActivityPub 的理解是，它可以帮助联邦化主题，甚至在 Discourse 实例之间共享分类。例如，discourse.joinmastodon.org 上的一个公告主题可以被联邦化到 socialhub.activitypub.rocks 的相关 #software:mastodon 分类中：在那里，本地用户可以像对待本地主题一样点赞、回复、引用等，只是原始主题仍保留在 joinmastodon 的实例上。

另一个方面是，如果用户在两个实例上都有账户，应该有一种方法将这些账户关联起来，即使用某个特定的 Discourse 实例作为主要身份提供者。我理解这并非首次迭代的核心重点，但值得铭记，因为我们最终可能会实现“使用 [在此填入你喜爱的 ActivityPub 实现] 登录”。

从上述提案中，我理解的是对 Discourse Android 应用的复制，其中包含实例列表，并能接收来自所有实例的通知。将来自多个来源的不相关回复混合交织似乎有些危险，尤其是当它们失去上下文时。

我的理解是否正确？我的理解是否适合作为你将 ActivityPub 与 Discourse 集成愿景的第二个步骤？

5 个赞
6

目前所有的 ActivityPub 实现都期望帖子由稳定的 Actor 发布，因此你可能需要以下方案之一：

  • 一个系统账户发布所有帖子
  • 每个可关注的订阅源对应一个账户
  • 每个可关注的订阅源对应一个账户，该账户对帖子进行 Announce，而这些帖子名义上是由每个 Discourse 用户账户创作的

第一种方案可能最容易实现；第三种方案在融合数据模型方面效果最好。

此外，我们还需要决定是发布完整的主题内容、仅发布主题的初始帖子，还是像 StackExchange 的 Twitter 订阅源那样，发布独立的帖子来推广来自 /top 页面的帖子。或者，这也可以只是“热门帖子”订阅源的工作方式，而其他订阅源则发布所有内容……

在技术层面，URL 无需更改：所有服务器都会发送 Accept: application/activity+json 或其替代格式。

我早就希望有一种 ActivityPub 阅读器应用，能够混合来自不同来源、在不同时间发布的订阅源，将“算法时间线”作为可选功能重现出来，而目前似乎还没有这样的应用。

@hellekin：我认为跨域创作极有可能严重破坏 Discourse 现有的许多反垃圾保护机制。实现阅读功能更为重要：毕竟，阅读是根本！

11 个赞
7

我不这么认为：远程用户仍可能被纳入预演，除非他们将远程账户与本地账户关联，在这种情况下，反垃圾邮件机制将适用于该账户。

Federation support for Discourse
8

我承认，我只是粗略地浏览了评论。我建议每个类别都作为一个独立的主体（类型为“群组”）。这样，外部人员就可以直接订阅特定类别。这些类别中的帖子可以通过让“群组”账号发布用户帖子来实现。这样我们就同时拥有了类别和作者。我们自己的软件就是这么做的。如果使用 JSON-LD 签名，即使是非公开类别也能确保安全。

问题在于如何处理来自外部的评论。我建议将群组账号设置为“需手动审核”。然后可以添加一些验证流程以避免随机垃圾信息。这些经过验证的账号随后就可以对这些帖子进行评论。

这将立即允许来自（几乎）整个联邦宇宙的人们与 Discourse 系统连接并进行互动。

7 个赞
9

我同意 @heluecht 的建议。

此外，我认为以下功能会非常棒：

  1. 每个分类组（Category Group）的参与者（Actor）都可以拥有一个所有者，该所有者拥有管理该分类的权限：控制发帖权限、封禁或移除用户、设置可见性（公开或私有）等。
  2. 本地用户可以在其实例上创建分类，前提是实例管理员批准其创建请求。
  3. 如果分类所有者无法胜任其职位，站点管理员可以更换他们。

这正是许多集中式论坛和社区的运作方式。需要改进的是如何实现联邦化（federating）。

不过，仍然存在一些问题：

  1. 参与者（Actor）的 id 是否应该是可变的？Discourse 的用户名可以在站点设置中设为可修改。然而，我怀疑其他 ActivityPub 软件是否能处理这种情况。Is Object's `id` immutable? - ActivityPub - SocialHub
    （更多内容待补充）
5 个赞
10

Discourse 团队的成员下周会参加 OFFDEM 的 SocialHub 吗？这将是一个与活动实施者见面和交流的绝佳机会。

7 个赞
11

据我所知没有，不过谢谢你的询问！

5 个赞
12

一些快速参考点：
Friendica 和 Hubzilla 可以将 RSS 源 转换为兼容 ActivityPub/Diaspora*/OStatus 的联邦账户。

另请参阅这个 WordPress 插件，它可将帖子转换为 ActivityPub 帖子。

10 个赞
Federation support for Discourse
13

还有一些参考点：

5 个赞
14

恭喜获得欧盟资金！

有路线图吗？

Discourse 团队有人参加 ActivityPub 大会吗？
这将是与其他 AP 实现者见面交流的绝佳机会。
https://conf.activitypub.rocks

5 个赞
15

我认为由于多种原因，此事实际上并未推进——那仅仅是一个 RFC 提案。

1 个赞
16

希望我们能在下周日 APConf2020 的“同类相聚”环节中讨论 Discourse 中 ActivityPub 的实现。相关专题已在 SocialHub 发布：

@rishabh，如果你周日无法到场，至少能在该专题中参与讨论就太好了。我们目前还不确定具体时间点，但活动将在周日早上举行。一旦确认，我会更新此帖。

7 个赞
17

嘿 @hellekin，

抱歉我没赶上。我想告知你，我们并没有申请 NGI0 资助，目前也没有人在负责这项工作。此外，由于我对该协议不太熟悉，我可能不是推动此事的最佳人选。不过，我会联系一下 @Falco，看看他是否有相关想法或兴趣来推进这项工作。

4 个赞
18

嗯，当时你们团队的一位成员确实提交了申请——尽管他现在已经不在团队中了，而且你们也被选中了——所以肯定有人批准了此事。因此，我不太清楚你所说的“我们”具体指谁。:slight_smile: 无论如何，我很期待与 @Falco 讨论此事。某种程度的 AP 支持将对 ActivityPub 社区非常有帮助，尤其是因为它能促进跨 Discourse 实例的协作，并更好地与 Fediverse 集成。

我确实关注反垃圾信息的问题，但我觉得可以通过将 Fediverse 用户视为“暂存”用户（类似于未注册邮箱的用户）来缓解这一问题，直到他们实际注册本地账户为止。

5 个赞
19

当然，能看到这一点确实很棒。

是的，我们过去确实申请过这笔资金，但今年早些时候我们与 NLnet 团队沟通后决定终止该项目，以便释放原本为我们预留的资金。即使当时我们已被选中，与 NGI0 的合作也暂时取消了。当然，我们未来可以自由提交新的提案。

我突然想到，@riking 可能也会感兴趣 :slight_smile:

1 个赞
20

有意思。

本项目通过 NGI0 Discovery Fund 获得资助，该基金由 NLnet 设立，并得到欧盟委员会“下一代互联网”（Next Generation Internet）计划的财政支持，由通信网络、内容与总司（DG Communications Networks, Content and Technology）监管，资助协议编号为 825322。

所以：他们说的是另一个

1 个赞
21

哦，我不知道还有这个页面。我会给我们的 NLnet 联系人写一封邮件，提醒他们（以防他们忘了删除它），并在这里发布一个更新。

编辑：更改已在 NLnet; Discourse ActivityPub 上线。

1 个赞