ActivityPub Support: Phase 1 RFC

There are many instances of Discourse. I don’t know exactly but I have accounts on a few dozens. It’s impossible to keep track of everything and many times I come across topics in distinct but no so different communities discussing similar issues, that could well be shared across instances since some of the participants are repeating themselves across discussions. It would really help to be able to share such topics across instances without having to login several times, cross-reference topics and not have a fluid discussion with interested parties.

Having ActivityPub users treated as staged users the same way emails users foreign to a Discourse instance are treated seems to be a good compromise to start with.

An RSS feed would certainly help you track ongoing topics at a single place but would not bring anything different from the Discourse Hub app, nor would it allow you to participate.

@hellekin I don’t know about this. Maybe you’re right, maybe you aren’t.
There are lots of nightclubs, restaurants, supermarkets, softwares, etc. Some are even pretty close. Geographically and/or in term of what they offer. Should one have the view that it’s “stupid” different places offering the same thing are separated? And these places should be merged to only have a centralized one?

Now, here, it’s a bit more evolved as the communities would stay kind of separated, but they are linked. Remains the question if all communities are the “same”: It is the same rules, the same atmosphere, the same kind of people, etc? This may be what makes a community a “special place” worth (actively) participating on: The fact that it’s unique. It has a unique vibe, a unique kind of humor going on, etc. A unique IDENTITY. People being a huge aspect of this: Who goes here or there. What kind of person.

Maybe this is a view on DIVERSITY: Mixing up everything, and ending up with something the “same” everywhere, because it’s so mixed up.

On the other hand, we have LINKS and QUOTES. Nothing prevents anyone from linking, quoting and summarizing what happens somewhere else. And here, you can keep the identity of each place, and not render everything the “same”.

Anyway, this may be the core questions behind the ActivityPub principle itself, and the willingness to implement it with Discourse. Of course, if it’s only optional, anyone can do as he wishes. and options are generally a good thing, IMHO (I’m not really sure why a successful community would want its content to be shared outside, and people to be able to interact with it from the outside).

[That’s a little some “Demolition man” thing where there are only Taco Bell restaurants left, isn’t it?]

1 个赞

I’m not sure how your view relates to my previous post. I did not say anything about merging communities, simply some common topics. And even then I only suggested user accounts could be the proxy…

And isn’t this, “merging” the offerings of different communities? You still “merge” some content, even if, as said in the previous message:

There seem to be a unwillingness to do it from the Discourse team, and an unclear advantages/use case on top of this. If you don’t see how my previous post relates to the subject, then ok. My apologies. forget about it.

Absolutely not. But I would like to read about them in my local newspaper, or - in a more specialized case - an Italian gastronomy guide for connaisseurs. The fact that things are not all the same, are what makes it worth subscribing to them. Back to the web and communities, linking an quoting are valuable of course. But they are another use case, different than sharing a topic between forums and viewing the thread in context, maybe participate directly.

You are right that in some cases you don’t want to mix identities and certainly not completely merge dispersed communities altogether. But you may selectively merge only those parts where it makes sense. Be it on a topic-by-topic basis, certain (sub)categories, tags or specific groups of people sharing content.

It is not really about ActivityPub either. The protocol is quite low-level, building on top of HTTP. You can build anything with it. Very often when mentioning ActivityPub, people automatically tend to think of microblogging (Mastodon) as that is the most popular application until now. If you consider this domain, everyone is sort of creating their own ‘unique community’ with it, defined by who they follow. This creates their personal timeline. Other than that they may have chosen to create their account on e.g. mastodon.technology and their server timeline loosely has the theme “technology” to it. But this domain does not really fit Discourse, of course. It is microblogging, not community forums after all.

Currently some microblogging applications are extending their domain with the concept of Groups. You might see this as a community concept that extends across the server boundary. So while I’m on mastodon.technology I might subscribe to the “spaghetti” group, and “climate change”. But it is still just microblogging → everything is compressed and flattened into my timelines.

What is a succesful community? What are its bounderies, what is inside and outside? These may be very clearly defined, and relate to identity and diversity. One thing they do not relate to per se, are specific server boundaries!

Though I went very broad in Community has no boundary, it is thinking without these artificial server boundaries I addressed (and how that may increase quality, quantity and activity of the community. I did not go into identity, which is a good point to also address). Thanks for responding there @Mevo, I’ll reply in due time.

5 个赞

Thanks @aschrijver , this is very helpful.
I take from the first paragraph the idea to “use it wisely”.
About the second paragraph, I was referring more to the idea of what it enables/does, than the protocol itself, when talking about “ActivityPub”. The “sharing/linking content” idea, or “freeing the content from servers boundaries”, like you talk about it.

The idea of some kind of shift of control/power is interesting: It would not really be the community owners who control anymore “their” users, “their” content (what they host, at least), what people have access to when coming to their place, how information is organized and grouped, etc. The users would be more in control and more free to pick what they want, from where they want, and make their “own menu”.

I can see how this may be appealing from the user’s POV, and how it may be a little scary/worrying from a community owner POV.

Taking a restaurant analogy, I agree I was probably getting a little too far with my point of merging several places, but I think your analogies are too soft: It’s more than what you describe, IMHO. It’s going to one restaurant and being able to order a dish from another place, made by the chef of that place. It may raise questions (which was a big part of my point) as to why the restaurant owner who pays well that chef, and maybe had troubles to attract him and retain him, would want to NOT have a clear reason for customers to come to HIS restaurant anymore. Your answer is kind of: It’s great from a customer POV. Yes, sure, I agree.

But anyway, you may be right on this, and the point I’m making looks quite like the fears of companies with open source in the past.

@angus 从 NGI 补助金处获得了支持此功能开发的资助,但该资助被拒绝了。我们将在明年申请另一项补助金。

2 个赞

那将非常棒。

2 个赞

有人能总结一下截至 11 月 22 日关于 Discourse 的 ActivityPub 实现的讨论现状吗?在阅读了许多相关帖子后,我目前的理解是这样的:

  • 2019 年曾尝试申请欧盟资助用于实现工作,但因某些原因撤回了申请
  • 到目前为止,还没有可以用于测试的代码(插件)
  • Discourse.org 的员工/核心团队对于“联邦宇宙化 Discourse”的需求没有统一的立场

这个理解正确吗?我在德国的一家大型政党工作,我们确实需要一种能够实例之间共享活动通知的去中心化 Discourse。因此,我对这些想法的当前状态很感兴趣……

5 个赞

是的。

我们使用多个 Discourse 实例来处理 Discourse,用户可以通过以下方式获得集中式通知:

  • Web 推送通知(适用于 Android、Windows、Linux、MacOS)

  • DiscourseHub(适用于我们托管的网站,适用于 iOS 和 Android)

  • 电子邮件(适用于任何地方)

更不用说能够订阅 RSS feed,通过 .ics 端点将书签同步到您的日历等。

为什么您需要 ActivityPub 来实现这一点?

5 个赞

是的,根据 OP,RSS 订阅源可能是拥有通用聚合互联网信息源的最佳解决方案。而且随着像 rss.app 这样的网站和 openrss.org 等运动的发展,如今你几乎可以获得任何你想关注的网站的 RSS 订阅源。

3 个赞

我们正在讨论中,可能还没有完全理解之前的讨论内容。

如果我们从集中式设置切换到去中心化设置,并使用多个 Discourse 实例(必须在欧洲本地托管,AWS 不在选项之列),一种“服务器到服务器”的活动消息传递方式将允许用户只登录一个系统,但仍能从另一个系统获取有关有趣活动的信息。

电子邮件“过于拥挤”,我们看到通过“标准新闻通讯”传播的信息覆盖率正在下降。ActivityPub(使用服务器到服务器 API)将允许在一个“首选服务器”上收集来自不同来源的信息。

RSS 订阅确实是一个可能的解决方案,但这需要在不同的服务器上进行注册/身份验证。而且,这需要手动操作,并且使用不同的技术,大多数“非技术”用户对此并不熟悉。

2 个赞

我非常希望能够邀请 Fediverse 的人们以比手动单框更丰富的方式参与我的 Discourse 服务器。

虽然我使用 RSS Feed(事实上,我用它来跟踪多个 Discourse 实例上的新内容),但一个仅支持出站的 ActivityPub / ActivityStream 插件将能触达人们聚集的地方,并有助于提高 Discourse 论坛信息的可用性。

我明白 Discourse 团队从根本上不同意这一点,这是他们的权利。Discourse 的巨大优势之一是,作为一个真正的开源项目,它是在公开场合构建的,而不是被扔过来的,我们不必意见一致。:smiling_face:

3 个赞

也许围绕 Discourse 中 ActivityPub 的想法还需要进一步成熟,包括技术和战略层面。

我希望当前的“推特灾难”能迫使更多人(尤其是政治层面的人)重新思考他们自己的“数字主权”出了什么问题。而且,也许这还包括为公共和社区数字讨论领域真正的开源解决方案带来新的机会……

3 个赞

到目前为止,我们一直在推动 Discourse 中的 ActivityPub,并听到许多人试图解释为什么他们需要 ActivityPub……但我们没有听到 @Discourse 团队为什么不想实现它。我试图用一些合理的方法来解决提出的每一个论点,但最终对于远程标识符如何改变信任级别仍然不清楚,因为远程帐户仍然可以被视为本地的_暂存_帐户,并像现在的暂存用户一样受到限制。

有多个相关帖子。我想强调的是,@sam 明确表示,我在这里将“话语团队从根本上不同意这一点”的说法是错误的或过时的:

我预计 CDCK 没有投入资源来完成这项工作的原因是,他们付费客户中很少有人关心这一点,或者至少不像其他功能那样重视它。我怀疑目前以及可预见的未来,社区对这项工作的兴趣远大于企业兴趣。如果 CDCK 承担这项工作,他们因未构建客户要求的其他功能而产生的机会成本可能会很大。(我对此没有内部消息。)

鉴于上面链接的 Sam 的评论,如果一群 Discourse 社区开发者足够关心并愿意构建一个插件,我预计 CDCK 会投入与这些开发者合作,审查和合并使该插件生效所需的任何核心更改。我为 Discourse 所做的少量贡献的经验是,他们优先审查和帮助处理他们自己不会优先做的工作。:heart:

7 个赞

作为一个简单的 Discourse 用户(托管了一个小型实例),而且是最近才开始使用的,我无法提供关于如何从技术上着手的确切建议。但我注意到 WordPress 通过其插件正在联邦宇宙中占据重要地位。截至 2023 年 2 月,已有 750 多个网站进行联邦,这已经超过了许多专门的联邦平台。因此,存在着将所有 Discourse 社区(如果它们愿意的话)“神奇地”融入一个更集成化的体系的潜力。主要需要注意的是(很可能)随着采用率的提高,联邦协议将会发展,因此这将是一个需要相关功能同步发展的承诺。

2 个赞

@SeriousFun01 阅读 Federation support for Discourse - #87 by angus 及后续帖子以获取此处更新。 :tada:

3 个赞