ActivityPub 支持:第一阶段 RFC

Continuing from Federation support for Discourse - #21 by rishabh, Tools to "aggregate" many Discourse forums? - #27 by Falco and ActivityPub Implementation for Discourse

Why?

A common problem that many Discourse users face is the inability to show an aggregation of all the interest groups that they are subscribed to. There’s no easy way to consume content from multiple Discourse instances in the form of a central and social user feed. Centralised platforms like Reddit get around this by having a single login for all communities and an aggregate feed of all the communities shown in a single stream on the reddit.com landing page. This latter feature is what we’d like to replicate in Discourse by means of the ActivityPub protocol.

For example, Person A frequents multiple Discourse instances: one for politics, two for hobbies, one for their local neighborhood forum but has no way to consume all relevant content in one single feed. In comparison, if you have joined multiple Facebook groups or Reddit subs, the most relevant posts already show up in your feed.

Spec (v1)

We could prototype an MVP by enabling the following features through a Discourse plugin:

  1. Generate an ActivityPub feed on demand (for every page that already has an RSS feed)

    • Similar to adding .rss to the url, this will allow the fetching of content using the AP protocol on requesting the right endpoint.

    • We may even be able to enable this for private content by appending user api keys to the url.

  1. Let forum admins enable ActivityPub (outgoing) on a per-category basis or keep it default-on?
    (I believe @Falco had some thoughts here)

  2. Figure out a way to consume this content on a Discourse forum / Mastodon feed (incoming)

Next Steps

We definitely need to start small so at first, we need to decide on a small, feasible set of features that will go into the first iteration. I’ve been going through the ActivityPub protocol but I’m not too familiar with the inner workings of it yet. Therefore, I’m inviting others who have shown a lot of interest in this to the discussion (@Falco, @hellekin, @merefield) to help us build a feasible spec for the first iteration and recommend changes for the spec above.

Resources

39 个赞

Here are a couple of highlights from the older topics :arrow_down:

Agreed, I think this is exactly how @Falco proposed that v1 could work.

6 个赞

Excellent initiative, thanks.

I would start by saying: shouldn’t we focus on the what not the how, initially? Tech arch comes later? The reason I say that is it might limit the functionality if chosen too early?

I would love to see for Version 1. a ‘Discovery of Discovery’ lists, starting with:

  • ‘Latest’ list which showed a preview of each recent topic from the included sources (simple union of Latest from all sources)
  • ‘Watched’ list, which showed a preview of each Topic that has activity you have selected to be notified about. (this takes its precedent from the existing mobile app - its exploding the notifications of new activity on watched Topics to the underlying Topic previews themselves).
9 个赞

Thank you for starting this!

I must say the original proposal involving Facebook analogy gets past my understanding: I have no clue what Facebook does, and I do not understand how it relates to Discourse in any way.

My understanding of ActivityPub support for Discourse would be that it can help federate topics, or even share a category among Discourse instances. For example, one announcement topic on discourse.joinmastodon.org could be federated to socialhub.activitypub.rocks in the related #software:mastodon category: there, local users could like, reply, quote, etc., as if it were a local topic, except the original topic would live on joinmastodon’s instance.

Another aspect of it is that if one has an account on both instances, there should be a way to link these accounts together, i.e., to use one specific Discourse instance as the main identity provider. I understand that this is not the focus of a first iteration, but it’s good to keep in mind, since we could end up having “sign in with [put your favorite ActivityPub implementation here]”.

What I understand from the proposals above is a replication of the Discourse app on Android, where you have a list of instances, and get notifications from all of them. It seems a bit dangerous to interleave unrelated responses from many sources, especially as they lose context.

Did I understand correctly, and would my understanding make a good second step for your vision of integrating ActivityPub with Discourse?

5 个赞

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

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

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

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

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


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


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

11 个赞

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

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

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

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

7 个赞

我同意 @heluecht 的建议。

此外,我认为以下功能会非常棒:

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

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

不过,仍然存在一些问题:

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

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

7 个赞

据我所知没有,不过谢谢你的询问!

5 个赞

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

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

10 个赞

还有一些参考点:

5 个赞

恭喜获得欧盟资金!

有路线图吗?

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

5 个赞

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

1 个赞

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

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

7 个赞

@hellekin

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

4 个赞

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

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

5 个赞

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

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

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

1 个赞

有意思。

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

所以:他们说的是另一个

1 个赞

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

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

1 个赞