以下是一个来自 Discourse 的潜在可行的出站联合支持想法：通过 Brid.gy 调解的 Webmention。
https://www.yusuf.fyi/posts/receiving-blog-replies-from-anywhere
流程概述：
参与者（注释“作者”）将采用高质量的站点徽标或 @system 头像，以及论坛的简称。
嘿，楼主
顺便说一句：我没有在帖子中提到，但该协议支持将点赞和转发作为一流公民发送，就像回复一样，如果 Discourse 也实现了这一点那就太好了。
这里有一个更新。Pavilion 和 CDCK (Discourse.org) 正在讨论为 Discourse 构建一个 ActivityPub 插件。经过一些讨论，我们确定了以下规范。在最终确定之前，欢迎提出任何意见或建议。请注意：
故意排除了对传入内容的支持（例如，将 Mastodon 等平台上的帖子导入 Discourse）。以后版本可以添加此功能。
还故意排除了对关注用户（而不是类别）的支持。以后版本也可以添加此功能。
规范的实质性部分遵循 Lemmy 的方法。
Pavilion 将构建 MVP 插件（我将负责），CDCK 将拥有并托管它（即，它将是一个 CDCK 插件，而不是 Pavilion 插件）。
Discourse 的 ActivityPub (AP) 插件。
该插件的目标是在 Discourse 中实现 ActivityPub、ActivityVocab 和 ActivityStreams 规范的 MVP 版本，并为 AP 兼容平台（即 Mastodon）提供一个演示集成 MVP 功能。在可能的情况下，实现将支持对协议及其任何扩展的进一步支持。
本规范涉及在每个类别基础上启用 AP 支持，其中 AP 启用的类别中每个主题的第一个帖子将被联合（“仅限第一个帖子”）。
插件的使用将在 meta 上的插件主题中进行全面记录。
使用类别的句柄（例如 @announcements@meta.discourse.org）在 Mastodon（或其他任何 fediverse 服务）上订阅（又称“关注”）一个联邦启用的 Discourse 类别（FDC）。
在其 Mastodon feed 中看到所有 FDC 主题的第一个帖子的摘录（在他们订阅后发布），每个帖子都带有指向相关主题的链接，例如“在我们的论坛上讨论”（URL）。
在 Mastodon 上与帖子相关的任何操作都不会显示在 Discourse 中。
在 Discourse 上与帖子相关的任何操作都不会显示在 Mastodon 中。
联邦帖子的摘录可以通过帖子作者使用类似于控制主题摘录的标记来控制，例如 <div>{text}</div>
使用类别设置在每个类别基础上启用联邦。联邦只能在对公共实例上的“所有人”可见的类别中启用。
通过类别设置 UI 设置类别的联邦用户名（无法更改）。
通过站点设置设置自动接受或拒绝活动的域的允许和拒绝列表。
设置一个联邦用户名的“阻止列表”，该列表将作为服务器发件箱中的 Block object(s) 的一部分。
使用站点设置设置联邦笔记的最大字符长度，即 activitypub_note_excerpt_maxlength。
在“自定义 > 文本”中设置与联邦 Discourse 主题的第一个帖子中包含的链接关联的文本。
在每个类别基础上设置是否在联邦帖子中包含指向论坛的链接（和文本）。
通过站点设置添加密钥对，用于签署联邦内容。
该插件将包含全面的测试（单元/集成和 js 测试）。
该类别是 Discourse 中一个自动化的 ActivityPub Actor（作为 Group ActorType）。联邦的 preferredUsername 由管理员在启用联邦时设置，并存储在类别自定义字段中。联邦名称（又称显示名称）是类别的 full_name。
用户是类别 Actor 在 Discourse 中联邦的内容的 Actor。联邦的 preferredUsername 是用户在联邦时期的 Discourse 用户名。用户的 preferredUsername 存储在用户自定义字段中，以防用户更改其 Discourse 用户名。联邦名称（又称显示名称）是用户的 Discourse 名称。
通常，ActivityPub 对象将通过自定义字段（例如，对象或 Actor ID）与它们等效的 Discourse 对象相关联，并在适当的地方使用新表（例如，收件箱和发件箱）。
要实现的主要 ActivityPub Activity 是 Follow 以及实现它所需的关联活动和模型，即收件箱、发件箱以及所需的关联操作和集合。
Discourse 帖子将被联邦化为 ActivityStream Notes，内容为 HTML。
身份验证将使用 HTTP Signatures 进行处理，请参阅此处和此处。ActivityPub 规范中的所有其他 Security Considerations 将根据需要进行处理。
联邦端点将根据规范进行适当保护，即确保在控制器中使用 redirect_to_login_if_required，并为所有人可见的类别添加 guardian 权限。
祝贺你完成如此宏伟的项目，我会非常关注 
我很高兴看到这个消息！谢谢！另外，很高兴你们从一个简单的初始实现开始，而不是试图“吞下象征性的象”（这并非对 Mastodon 的含蓄提及）。我犹豫是否要提出添加任何内容，但既然你们征求建议，我希望有一个工作量微不足道但很有用的建议：
你们觉得是否可以另外选择性地发布回复的摘录，并使用 inReplyTo 来将它们串联起来？我认为这将突出 Discourse 上发生的对话，并更具吸引力；再加上“在我们的论坛上讨论”，我预计看到对话更有可能吸引更多人加入。
感谢您的反馈和支持！
现阶段联合发布回复的问题在于，您可能会产生一些期望，而这些期望在您拥有适当的支持之前将无法实现。在此处保持用户期望的清晰非常重要。虽然有些用户可能会理解联合回复的局限性，但其他用户可能不会。另一个问题是试图一次性减少要解决的技术挑战数量。
话虽如此，我们已经考虑过将“整个主题”扩展到您上面看到的“仅第一个帖子”规范。我已在此处分享了一些技术笔记，以让您了解这可能的发展方向。我想强调的是，“整个主题”扩展不是初始规范的一部分，目前只是一个可能性。
将尽可能使用 Accept / Reject objects 来将 Discourse 的安全和垃圾邮件过滤器应用于入站对象。
笔记帖子将通过自定义字段归因于与参与者 ID 关联的暂存用户。这将需要暂存用户概念的非电子邮件变体，因为用户将没有真实电子邮件（可以使用联合参与者的 ID 和 preferredUsername 生成占位符）。
将暂存的 ActivityPub 用户与标准 Discourse 用户关联是可能的，但目前不包含在此规范的任何部分中。这是“联合身份”及其解决方案的问题。
联合帖子将不支持联合 @提及，或核心 ActivityPub/Stream 规范之外的任何类似功能。可以在后续版本中添加对此类功能的支持，例如使用 Webfinger 或 遵循 Mastodon。
此初始版本中的关键是专注于最小可行实现。一旦奠定了基础，更全面（或更完整）的联合支持，可能类似于那些“整个主题”的笔记，将更加可行。但我会强调，插件的方向将由 CDCK 决定。我在此处提到的任何内容都只是基础规范可能构建的潜在方式。
Fediverse 的一些帖子和正在进行的讨论：
PS。我还想提一下，去年 11 月，Flarum 的核心开发者 Daniël Klabbers 联系了我，他告诉我他们正在开发一个 ActivityPub 扩展。我不知道目前的进展如何，但如果论坛领域的项目能够协同工作，在该领域实现尽可能多的互操作性，那将是件好事。
关于互操作性，我还想指出 Codeberg 上的 Fediverse Enhancement Proposal（FEP）流程：
例如，Lemmy 最近完成了一个关于 ActivityPub Groups 的 FEP。讨论在 SocialHub 上进行：
（随着 Fediverse 的发展，FEP 流程正在加速，目前是标准化协议机制的最佳场所）
感谢 @aschrijver，非常有帮助！我将专注于上面规定的 MVP（最小可行产品）的实施，并与 CDCK 密切合作。用 @mcdanlj 的精辟话来说，关键是这项工作不要试图“吞下大象”。我们热切希望听到对该规范的任何建设性反馈，尤其是在技术方面。
不过，我想补充一点，Pavilion 的另外两位成员 @nmeyne（SSI（可验证凭证）社区的资深人士）和 @merefield 也在从事这个领域的工作，他们对您提出的一些更广泛的问题很感兴趣。
好的，谢谢。我已通过私信通知 Daniël Klabbers，并告知他你上面的公告。
这对我来说完全说得通！
为了说明由于忠实度的错觉而产生的真正误解，我们在 Maker Forums 上遇到过的一个问题是，当 Google+ 关闭时，我们导入了大量的 Google+ 社区。导入的忠实度足够高，以至于新用户不意识到他们正在尝试与尚未（或还）从 Google+ 迁移到该网站的其他用户互动，因此我们有一个预设回复，告知他们他们试图交谈的人不在那里回应他们。
感谢您提供关于“整个主题扩展”想法的详细信息。
以防将来添加此功能……供参考，我非常喜欢 Pterotype for WordPress 所提供的方法，即任何联合评论都会直接转交审核/小组批准，然后才能作为回复发布回原始论坛主题。
在这种情况下，这项任务可能更适合 TL4/TL3 用户，而不是工作人员。
我个人发现，这在防止离题/社交媒体风格的回复压倒原始讨论主题方面特别有帮助。
是的，使用审核队列是我们讨论过的关于接收内容的方式。正如你所指出的，这是我们到达那里时（而不是在第一个版本中）需要考虑的事情。
请注意，有关这项工作的管理事宜已经解决，我将在下周开始着手处理规范。欢迎对规范提出任何进一步的技术反馈或意见。
这项工作需要几个月才能完成，请耐心等待。
如果在 Discourse 中删除了帖子，是否可以将“删除”操作发送给关注者？
在 Maker Forums 上，我们有足够的“谷歌积分”，因此会收到大量的 SEO 垃圾邮件。我们对新用户的权限相对宽松，因为新用户的一种常见形式是寻求与网站相关帮助的沮丧的人，这有助于我们更快地帮助他们。但这意味着垃圾邮件发送者往往会发布垃圾邮件，然后很快被标记为垃圾邮件、下架，然后删除。
我希望这些联合帖子能够被删除，并通过“删除”发布删除信息，以便我们清理联合缓存中的垃圾邮件。这是否可能在范围内？
在这种情况下，如果联邦化有几个小时的延迟，以便在联邦化之前处理垃圾邮件，可能会有所帮助。（也许甚至只对相对较新用户的第一个帖子应用延迟？）
都很有用的建议，谢谢。
我预计我们将在 MVP 中做到这一点，原因与你提到的类似。我将在适当的时候与 Discourse 的人们进一步讨论。
有用的建议。联合（Federation）肯定会是异步的。延迟如何设置和处理是我们需要在 MVP 中以某种方式解决的问题。
像这样的 MVP 具体建议，特别是基于先前的用例或技术领域专业知识的建议，都非常受欢迎。
如果前期工作量没有显著增加，将帖子编辑作为 Update 活动进行联合也会很有价值。如果这是 MVP 之后可以贡献的内容，那么一个能合理地容纳以后添加它的设计将是很好的。
就我个人而言，我会在我的实例上将延迟设置得很低。我不会计划使用它来避免联合垃圾帖子，因为这很可能会成为一个信号，将版主从他们的 fediverse feed 引入我们的 Discourse 来采取行动。我已经将 chat_integration_delay_seconds 设置为 20，用于快速的拼写错误编辑，并且期望在这里做类似的事情。至少，该设置为此类延迟设定了先例。
这里有一个简短的更新！我们已经开发了一个月，总的来说，我们现在有了以下功能：
还有一些小的方面，但在这个阶段不值得深入讨论。在开始内部测试之前，至少还需要一个月的开发时间。
总之，开发进展顺利
这太棒了，感谢分享。
我们需要在我们可以构建的每一个方面都拥有自由，无论是否获得中心化服务的批准。
这是不可阻挡的，而且对于每一个CEO、CTO或任何奇怪名字的决策者来说，都是唾手可得
也非常感谢所有参与的开发者以及他们取得的进展。我将在公开后进行测试并分享我的想法。
太棒了，那样的话是否也适用于标签？目前我们的用户通过 RSS 订阅我们的标签。
总之，恭喜！这非常令人兴奋。