我明白了。
相当令人沮丧。
朋友们因为即将到来的 ActivityPub 而转向 Discourse。
现在他们又开始诋毁 Discourse……
此外，ActivityPub 的官方论坛也迁移到了 Discourse，现在我们
不得不讨论该如何应对……
Lemmy 背后的开发者在将 ActivityPub 适配为社区软件可用这一方面做得非常出色：
https://github.com/LemmyNet/lemmy-docs/blob/main/src/en/federation/overview.md
不过，他们不得不对其进行扩展，因此目前没有其他软件实现他们的活动。
我们的联邦实现已具备完整功能，但迄今为止我们完全未专注于符合 ActivityPub 规范。因此，Lemmy 很可能无法与期望发送和接收有效活动的实现兼容。
我想，如果 Lemmy 能够使其与 Mastodon 兼容，我们就可以着手实现 Lemmy 所使用的相同 API，并进行如下映射：
| Discourse | Lemmy ActivityPub |
|---|---|
| Category | Community |
| Watching | Follow |
| Topic | Post |
| Post | Comment |
| Like | Like |
19 个赞
在活动语汇（ActivityPub）中，这应该是一个 Page（页面），考虑到页面的发布功能，这一点非常合理：第一部分会被宣告为 Page，随后的任何回复则会是 Note（笔记）。
我对 Category（分类）映射到 Community（社区）这一点还不确定。由于 AP 支持和单点登录（SSO）使这一切更加灵活，我倾向于为单个社区部署多个 Discourse 实例。
5 个赞
顺便提一下，以下 Discourse 实例开始共享用户和主题，而 Discourse 中的 ActivityPub 将对我们所有人非常有用：
https://love.public.cat/t/what-is-at-stake-with-interoperability/96
7 个赞
真可惜，Discourse 尚未向实现 ActivityPub 迈进。考虑到已有如此多的社区在使用 Discourse，若能从第一天起就受益于此，潜力巨大……哪怕他们目前尚未意识到这一点！
3 个赞
你好 @rishabh、@riking、@codinghorror，
（是的，下面有 TL;DR 摘要）
之前我从 @sl007 和 @hellekin 那里了解到，即使有 NGI0 的资金支持，你们在短期内也不会推进这一阶段（Phase 1）。作为同样推崇基于 ActivityPub 的互操作性的支持者，我当然也觉得这很遗憾。但从 Discourse 的角度来看，作为领先且最受欢迎的论坛软件，其中涉及诸多力量和优先级考量，因此在此背景下做出的这一商业决策可能非常合理：
决策：本 RFC 按当前提议的吸引力不足，因此未被优先考虑，也未列入路线图。
该 RFC 采取了最小可行产品（MVP）的方法，即按照 @Falco 的提议，“首先创建一个类似 Facebook 的跨论坛聚合内容流”。这仅仅是拥有某种形式的原生 ActivityPub 支持后可能产生的众多功能之一。可以说，这样的时间线某种程度上偏离了论坛通常具备的功能，对我而言，这似乎并非真正的核心功能，而更像是一个附加扩展，因此属于“锦上添花”而非“不可或缺”。
另一种方法
既然不再需要急于推出 ActivityPub 支持的 MVP，或许我们可以反其道而行之：
构思：头脑风暴各种互操作用例，并从商业利益和独特卖点（USP）的角度评估其可行性。
也就是说，哪些功能真正值得在 Discourse 中实现？或者更进一步：如果 Discourse 不了解这些可能性，可能会错失哪些机会？
在 @Falco 的 最新帖子 中，他提到了 Lemmy。Lemmy 完全基于与其业务领域相匹配的专用链接数据词汇表构建。他们已准备好 MVP 并投入生产，现在正致力于在其自身领域基础上扩展功能集。这可能包括与另一个领域（即微博领域，Mastodon、Pleroma 等在此领域非常成功）进行联邦互联。
构思过程或许可以遵循以下练习：
练习：让我们设想，如果 Discourse 从一开始就基于其自身的基于 ActivityPub 的业务领域（定义为链接数据词汇表）构建，它会是什么样子。
让我们在这个头脑风暴会议中尽情发挥，让创意自由驰骋。
由此产生的用例列表，如果从商业角度看来足够有趣，或许可以成为路线图的一部分；即使不能，它们也可能激励社区开发插件和组件，为后续阶段的建设奠定基础。
ActivityPub 与 Fediverse
我注意到，关于在应用程序中支持 ActivityPub 的含义，存在广泛的误解。许多人认为这样做的原因是为了“成为 Fediverse 的一部分”。于是，人们的思路立刻转向与 Mastodon 实例进行联邦，即实现与（加入）联邦式微博领域的互操作性。
是的，一旦拥有 ActivityPub 支持，这是一个非常有吸引力的机会。许多其他应用程序，如 PixelFed（Instagram 的替代品）、PeerTube（YouTube 的替代品）以及 Lemmy（Reddit 的替代品），都在寻求实现这一目标。它们使 Fediverse 成为一个更具吸引力的参与空间，并且大量创新正在形成，让 Fediverse 的未来令人兴奋。
但是……
可以认为，像 Discourse 这样面向庞大用户群的组织可能会提出这样的问题：“我为什么要与仅拥有约 400 万用户的 Fediverse 集成？”或者“我为什么要将微博功能集成到完全处于不同领域的软件中？”他们完全有理由这样陈述，并基于此前提放弃 ActivityPub 的实现。
然而……
ActivityPub 的实现远不止于成为（Fediverse 中的微博部分）的一部分。为自身的业务领域设计独特的链接数据词汇表，并让自身的产品实例相互联邦，或者让自身产品及同行业竞争对手（如果他们也采用相同词汇表）的所有实例相互联邦，这完全合乎逻辑。
一个例子是 ForgeFed 项目，该项目旨在为代码托管平台（如 GitHub、GitLab、Gitea、Sourcehut 等）制定互操作性标准。这样做非常有意义，尤其对于较小的代码托管项目而言，可以提供具有吸引力的 GitHub 替代方案（GitHub 已变得过于主导，成为一个日益封闭的围墙花园平台）。如果广泛采用，开发人员将不再需要在互联网上分散的服务器上管理众多代码托管账户，以参与有趣的代码项目、提交问题、发表评论和提交 PR。
（请注意，正如上文所指出的，人们对于独立代码托管平台遍布各处所面临的问题，也正是我和其他人在参与众多 Discourse 社区时所体验到的。）
机遇：Discourse 处于独特位置，可以引领论坛软件的互操作性标准制定，并以与当前 Discourse 功能集完美契合的方式塑造该标准。
贵行业有一些新兴竞争对手，他们具有创新性，采取新方法，并快速迭代以添加新功能（在 Discourse 工作的你们最清楚这些竞争对手是谁 
）。就功能完整性而言，Discourse 仍然远远领先于它们的产品。而且，你们拥有无与伦比的社区来协助产品演进。
但现在存在的互操作机遇也可能转变为威胁。要么竞争对手率先抓住这一机遇，要么——在欧盟《数字市场法案》的推动下——大型科技平台可能会创建与论坛软件领域重叠的产品。在这两种情况下，Discourse 都将更难与该标准保持一致，并在其规范设计中发挥最具权威性的声音。
TL;DR
这篇帖子比我预期的要长。对此抱歉 
总之，我的观点是，鉴于目前对支持 ActivityPub 的立场，从短期的 MVP 式焦点转向更广泛地评估 ActivityPub 互操作性能为 Discourse 带来的独特卖点（USP）和长期定位，可能是明智之举。也就是说，阐述采用 ActivityPub 的商业案例，从构思阶段开始。
（如何最好地组织这项工作——如果您感兴趣的话——我将其留作中间环节，但它可以简单地从一个新的 AP 主题开始，顶部有一个收集用例的总结 Wiki，人们在该主题中讨论用例想法。）
11 个赞
Arnold，如果你能获得资金支持，是什么阻碍了你将此功能开发为插件呢？
有时，在插件中开发和验证功能，有助于更广泛地推广并被核心采纳。
一个很好的例子是“主题列表预览”（这是一个插件）。缩略图预览最初完全是临时拼凑的。如今，由于其受欢迎程度得到验证，Discourse 核心已原生支持缩略图。
我和@angus 将其开发到一定程度后，核心团队认为该想法已足够成熟且足够受欢迎，于是决定自行实现。
这种方法可以降低风险，并有助于在纳入核心路线图之前克服实际障碍。
仅供参考……
9 个赞
市场里原本已有一项资助提案，曾被 Discourse 团队中的某位成员接手，但随后该被接受的提案被搁置。目前该资助机会仍然开放，但需要一家欧洲实体来承接。这或许是“馆阁”（The Pavilion）的一位欧洲成员。我很乐意协助完善提案，因为复用现有提案无疑有助于加快其获得成功资助的进程。
5 个赞
我们当然可以线下讨论如何妥善处理此事。
4 个赞
你提供的 Dansup 链接让我想起了过去几年可用的 WordPress ActivityPub 插件。类似于这位用户，我从这些插件发布之初就在自己的 WordPress 站点上运行它们：ActivityPub 插件 以及目前活跃度较低的 Pterotype。
你的站点会被转换为联邦宇宙中的一个参与者（actor），例如 @latest@meta.discourse.org。你可以为账户添加描述，站点图标将显示为你的联邦用户头像。帖子会出现在联邦宇宙中供其他用户查看，而他们的评论则会显示在我们的网站上，并展示其联邦用户头像和名称。
示例回复：
@doug@mastodoon.social:
我一直很享受关注这个关于联邦化的讨论线程！继续加油
这非常棒，因为它在 WordPress 上显示为普通评论，同时通过 ActivityPub 也作为真正的联邦评论存在。
编辑：不妨看看 Prismo，这是一个基于 Ruby / PostgreSQL 构建的联邦化 Lemmy/Reddit 变体，其设计理念可能与 Discourse 更为契合。
3 个赞
嗨 @merefield，
开发插件确实是一个非常可行的选项。在我的推演中，我提议“假设”Discourse 从一开始就将联邦化（federation）作为核心设计思路，以此开放心态去探讨所有可能性，而暂时不局限于当前产品和生态系统所能实现、可行或不可行的范围。我们提出的每一项构想，都可能非常适合通过插件形式来实现。
我本人主要致力于联邦宇宙（Fediverse）的不同方面。我的回复既出自一位 Discourse 的忠实粉丝和倡导者，也源于我对联邦宇宙的支持——我认为，尽管联邦宇宙充满创新，但它正是成为下一代以人为本、更具人文关怀的社交媒体格局的绝佳机会。
不过，在我上面的帖子中，我想强调的是，即使不涉及联邦宇宙集成，也存在一个完全独立的互操作性用例，即不同 Discourse 社区之间的直接互通。附注：我已在 SocialHub 论坛上跟进，以唤起人们对 ActivityPub 支持这一方面的关注：Positioning ActivityPub: De-Emphasize "Being Part of the Fediverse" as primary USP - Fediverse Futures - SocialHub
非常感谢，这个想法很棒。我希望本主题帖能激发任何插件开发者去探索其中的可能性。
是的，非常棒。这些项目可以为 @merefield 所谈论的 Discourse 插件方向提供很好的灵感，尤其是当聚焦于联邦宇宙支持时。
4 个赞
我们过去曾得出结论：Discourse 与 Discourse 之间的联邦化毫无意义；我们已通过 OpenGraph 实现了基本的互操作性，这似乎已经足够。如果任何人有令人信服的使用场景，我很乐意听取，但截至目前尚未见到任何此类案例。你们只讨论了技术可能性，而没有说明这项技术实际上能支持哪些产品功能。
4 个赞
说得很好！如果目标是将一个论坛的帖子与另一个 Discourse 论坛的帖子同步……你其实已经可以使用 matterbabble 配合 matterbridge 来实现。
1 个赞
不，你说得对。这正是我建议我们要做的（在我的 TL;DR 中，我提到“阐述采用 ActivityPub 的商业案例，从构思阶段开始”）。
由于这个头脑风暴提案远远超出了本主题帖的讨论范围，而且并未针对单一功能或 RFC，而更像是一种愿景，因此我已在 #community 分类中创建了一个独立的主题：
5 个赞
请查看一份提案，旨在梳理一个商业用例，以此作为说服 @riking 对 Discourse 实现 ActivityPub 支持的起点 @merefield，你愿意加入那里的讨论吗？——当然，如果原生支持 AP，一切都会变得简单！
4 个赞
如果我说错了请见谅，但为什么不使用 feed2toot 将 RSS 源转换为 ActivityPub 呢？我看到它支持 Mastodon 和 Pleroma。Discourse 默认会为分类和群组生成 RSS 源。Hubzilla 和 Friendica 也内置了对 RSS 的支持。
这不应该是“单向”的吗？即“从”Discourse“到”ActivityPub 实例，而不是反过来。
@hellekin 请原谅我，但我实在看不出这里的“用例”是什么。我的意思是，为什么要这么做，有什么好处等等。
重读该讨论串，并在 Community has no boundary: Discourse-as-a-Fabric - ideation & brainstorm 上展开讨论后，又回到 Shaping Up a Business Use-Case for ActivityPub in Discourse - Fediverse Futures - SocialHub 继续思考，我意识到没有人曾要求在此详细说明原因，这大概是我以及其他 ActivityPub 支持者的疏忽。对此深感抱歉。
能否请您进一步说明，是什么阻碍了 Discourse 更深入地探索联合功能？同时，ActivityPub 社区可以在哪些领域为您提供更多信息和支持，以激发您的兴趣？
3 个赞