# Discourse 的联邦支持
**URL:** https://meta.discourse.org/t/federation-support-for-discourse/90921
**Category:** Feature
**Tags:** completed
**Created:** [2018年六月28日 05:32 UTC](https://meta.discourse.org/t/federation-support-for-discourse/90921 "2018-06-28T05:32:10Z")
**Posts on this page:** 20
**Page:** 4
### Author:  [@Mr.X\_Mr.X](https://meta.discourse.org/u/Mr.X_Mr.X)
#### Post date: [2022年六月7日 10:42 UTC](https://meta.discourse.org/t/federation-support-for-discourse/90921/64 "2022-06-07T10:42:53Z")
是的，但这将是一个广泛且昂贵的插件。
---
### Author:  [@Mr.X\_Mr.X](https://meta.discourse.org/u/Mr.X_Mr.X)
#### Post date: [2022年六月7日 10:43 UTC](https://meta.discourse.org/t/federation-support-for-discourse/90921/65 "2022-06-07T10:43:30Z")
使用 SSO 或 LDAP 是否可以允许双向登录，而无需将所有人都迁移到单一域登录？
例如，我有论坛 A、B 和 C。我希望论坛 A 的成员能够使用其论坛 A 的凭据登录并发布到论坛 B 和 C。注册了论坛 B 和 C 的成员也应该能够做到这一点。
---
### Author:  [@hellekin](https://meta.discourse.org/u/hellekin)
#### Post date: [2022年六月17日 17:52 UTC](https://meta.discourse.org/t/federation-support-for-discourse/90921/66 "2022-06-17T17:52:50Z")
我认为此帖及后续帖子应移至自己的主题，因为它们涉及此处讨论的功能的一个子集。
---
### Author:  [@isaac](https://meta.discourse.org/u/isaac)
#### Post date: [2022年六月17日 17:58 UTC](https://meta.discourse.org/t/federation-support-for-discourse/90921/67 "2022-06-17T17:58:10Z")
> [@Mr.X\_Mr.X](#):
>
> 使用 SSO 或 LDAP 是否可以实现双向登录，而无需将所有人迁移到单一域登录？
[Setup DiscourseConnect - Official Single-Sign-On for Discourse (sso) - Integrations - Discourse Meta](https://meta.discourse.org/docs?topic=13045) 可能会对您有所帮助 🙂
---
### Author:  [@mcdanlj](https://meta.discourse.org/u/mcdanlj)
#### Post date: [2022年六月26日 04:57 UTC](https://meta.discourse.org/t/federation-support-for-discourse/90921/68 "2022-06-26T04:57:42Z")
理论上，除了制作一个充当 ActivityPub 联合协议服务器的 Discourse 插件之外，另一种可能性是设置单独的 ActivityPub 服务器上的账户，该服务器支持\_客户端\_社交 API 协议，并让 Discourse 插件与该服务器通信客户端协议，而不是充当 ActivityPub 服务器。这可能有利于更紧密地集成到现有的 ActivityPub 节点中。但我不认为它比服务器协议更容易实现，而且对于论坛运营商来说，它比充当联合协议服务器需要更多手动设置工作。
在我设想的实现方案中，为了允许用户交互的可能性，必须有一种方法来区分 discourse 用户参与者和 discourse 系统参与者（例如，类别）。我可以想象 `@#slug@discourse.example.org` 将是一个类别参与者，为稍后添加 `@username@discourse.example.org` 用户参与者留出空间。但考虑到标签的普遍性，这可能在实践中行不通。
更简单的做法是，只关注第 1-3 点，认为第 4-5 点接近于试图将 Discourse 转变为通用 ActivityPub 服务器，但这绝对不是目的。
---
### Author:  [@mcdanlj](https://meta.discourse.org/u/mcdanlj)
#### Post date: [2022年七月8日 23:35 UTC](https://meta.discourse.org/t/federation-support-for-discourse/90921/69 "2022-07-08T23:35:34Z")
Mastodon 使用以下正则表达式进行验证：
```ruby
USERNAME_RE = /[a-z0-9_]+([a-z0-9_\\.-]+[a-z0-9_]+)?/i
MENTION_RE = /(?\u003c=^|[^\\/[:word:]])@((#{USERNAME_RE})(?:@[[:word:]\\.\\-]+[[:word:]]+)?)/i
```
据我所知，`USERNAME_RE` 应用于\_远程\_用户，因此我不清楚如何将 Discourse 用户和类别放在不同的命名空间中。它也排除了正常的子类别 slug。`@parentcategory:subcategory@discourse.example.org` 也不适用于该正则表达式。
我猜可以有一个可选的子域名 `@username@users.discourse.example.org`，但这需要更多的 SSL 和 DNS 设置，并且可能会经常配置错误。也许不值得这样做。
---
### Author:  [@volanar](https://meta.discourse.org/u/volanar)
#### Post date: [2022年七月9日 00:40 UTC](https://meta.discourse.org/t/federation-support-for-discourse/90921/70 "2022-07-09T00:40:31Z")
也许与其他平台建立联合体没有意义，而是应该在所有 Discourse 实例之间建立联合体，因为 Discourse 实例的数量非常庞大。
---
### Author:  [@mlgtechuser](https://meta.discourse.org/u/mlgtechuser)
#### Post date: [2022年七月9日 16:22 UTC](https://meta.discourse.org/t/federation-support-for-discourse/90921/71 "2022-07-09T16:22:59Z")
这里肯定有巨大的潜力。可能性和可行性值得认真、审慎地考虑。
> [@volanar](#):
>
> 在所有实例之间创建一个联合
这可能是“香格里拉”的领域……（阅读上面 Jeff 的帖子 [**Jeff’s post above**](https://meta.discourse.org/t/federation-support-for-discourse/90921/12) 并关注其中的链接。） 如此广泛的集成可能也是大多数 Discourse 实例的管理员/运营商不希望的。应该对管理员和运营商进行正式调查（而不是在讨论论坛中进行“按流量水平调查”）。
> [@buoyantair](#):
>
> - 想象一下，能够连接到您自己的本地社区，然后能够从您关注的其他 Discourse 社区获取有关其他主题的新闻！
> - 您不再需要在每个 Discourse 社区中创建帐户，因为您可以随时订阅并评论这些社区中的主题！
这似乎是在邀请安全漏洞，因为它会暴露任何能够破解其中一个联合站点的用户凭据的人的“王国之钥”。至少，这些功能必须默认关闭，或者作为插件显式加载——并启用大多数安全功能并进行锁定。Zoom 通过在快速获得用户和培养用户方面保持其平台开放和易于使用（以快速获得和培养用户）给我们上了这一课，但一旦不法分子发现前门未锁，就不得不迅速将其锁定。
尽管如此，站点的微联合将促进 Discourse 的实施。如果我能为我的市政当局创建一个站点圈，将相同的用户池（例如，县/市公民）联合起来，这将使人们进行交流，并可能带来一些积极的成果，以改善地方治理和社区生活。同一原则也适用于任何足够大的企业，可以证明管理多个 Discourse 实例的开销是合理的，以便每个部门都可以拥有自己的 Discourse 容器，并可以轻松导航到其他部门。_ **那** 将是 **meta.discourse** 的体现。_
然而，Jeff、Sam 和 Co. [@codinghorror @sam] 和/或他们的指导委员会首先需要决定 Discourse 是一个 **社交平台** 还是一个 **企业平台** 。我投票支持企业，因为我看到了这两种选择的巨大潜力。企业将通过改善企业支持员工的能力（好好对待企业，企业就能好好对待你）来产生最大的经济回报和直接的社会效益。其中一些商业资金可能随后支持 `social.discourse.org` 基金会。对企业有用的功能也很可能很好地迁移到社交领域。这两个因素共同促成了一个双赢的局面。
这两个领域需要区分开来，因为它们差异很大。并且“锦上添花”的功能必然需要偏向于主要用例的版本。
令人高兴的是，这两种方式都有好处，因为任何对 `social.discourse.org` 感兴趣的人都可以从社区建设的社交方面获得回报，并能够追求与社区相关的活动，因此他们会努力——并且经常努力——为这些非经济回报而工作。这种 `social.discourse.org` 工作将不可避免地带来对企业领域有用的开发和功能，从而为 Enterprise Discourse Incorporated 带来价值，以换取对 Social Discourse Foundation 的非营利性支持。甚至更多的双赢。
请注意，上面没有一个感叹号。这些只是事实陈述和可能结果的陈述。非常务实。
几年来，我一直在为我的企业寻找合适的群件平台。Slack 曾短暂地带来过很高的希望，因为它最初是为内部业务开发的（并且有一个非常有趣的[**起源故事**](https://www.npr.org/2018/07/27/633164558/slack-flickr-stewart-butterfield))，但甚至没有通过第一轮筛选。我对 Discourse 印象深刻，并对其充满乐观。
---
### Author:  [@merefield](https://meta.discourse.org/u/merefield)
#### Post date: [2022年七月9日 17:08 UTC](https://meta.discourse.org/t/federation-support-for-discourse/90921/72 "2022-07-09T17:08:45Z")
> [@volanar](#):
>
> 但要在所有 Discourse 实例之间创建一个联合
这正是本主题的重点，即在 Discourse 实例之间。
在 OP 中已说明：
> [@buoyantair](#):
>
> 此功能的主要目标是连接所有 Discourse 社区
---
### Author:  [@mlgtechuser](https://meta.discourse.org/u/mlgtechuser)
#### Post date: [2022年七月9日 22:39 UTC](https://meta.discourse.org/t/federation-support-for-discourse/90921/73 "2022-07-09T22:39:31Z")
好的，还有
> [@mlgtechuser](#):
>
> 这可能是“Xanadu”的领域……
还有
“一个微型联盟的网站将是一个促进”
都在主题内，对吧？ 😃
---
### Author:  [@merefield](https://meta.discourse.org/u/merefield)
#### Post date: [2022年七月10日 06:47 UTC](https://meta.discourse.org/t/federation-support-for-discourse/90921/74 "2022-07-10T06:47:53Z")
> [@mlgtechuser](#):
>
> Jeff、Sam 和 Co.（[@codinghorror @sam]）和/或他们的指导委员会首先需要决定
不一定需要。还需要考虑插件生态系统。
规模较大的功能通常会作为插件甚至主题组件（在可能的情况下）进行开发，这些功能不需要行政开销或集中规划。
这正是 Discourse 生态系统的魅力所在。
例如，[Pavilion](https://thepavilion.io/welcome) 在未与 CDCK 协商的情况下创建了 Locations、Topic List Previews、Multilingual、Follow、Layouts、Custom Wizard（仅举几例）。因此，部分原因是我们参与了这次讨论。
---
### Author:  [@mlgtechuser](https://meta.discourse.org/u/mlgtechuser)
#### Post date: [2022年七月10日 17:17 UTC](https://meta.discourse.org/t/federation-support-for-discourse/90921/75 "2022-07-10T17:17:04Z")
愿上帝保佑我们的插件开发者！他们慷慨地提供可供现场测试并考虑纳入核心产品的概念验证示例。您的多语言插件就是一个绝佳的例子！
在 [python.org](http://python.org)，这个角色由库开发者扮演，他们有时会创建“必须拥有”的功能，这些功能会被接受并纳入 Python 核心包或标准分发库。
---
### Author:  [@aschrijver](https://meta.discourse.org/u/aschrijver)
#### Post date: [2022年十一月28日 06:20 UTC](https://meta.discourse.org/t/federation-support-for-discourse/90921/76 "2022-11-28T06:20:03Z")
我一直在论坛的多个主题中倡导 Discourse 添加联合支持，例如 [此处](https://meta.discourse.org/t/community-has-no-boundary-discourse-as-a-fabric-ideation-brainstorm/174578)。随着 Fediverse 如今成为主流，Tumblr 以及可能的 Flickr 等也添加了联合支持，问题是 Discourse 是否有更大的兴趣添加支持。
Flarum 的核心开发者联系我，就 AP 实现提供建议，我将一些链接发回，其中包括刚才提到的那个。
PS. 在 [SocialHub](https://socialhub.activitypub.rocks) Discourse 论坛（Fediverse 的开发者社区）上，我们长期以来一直在寻找如何成为 Fediverse 的一部分，因为独立的论坛对大多数人来说参与门槛太高了。
---
### Author:  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [2022年十一月28日 20:36 UTC](https://meta.discourse.org/t/federation-support-for-discourse/90921/77 "2022-11-28T20:36:08Z")
> [@aschrijver](#):
>
> 我一直在论坛的多个主题中倡导 Discourse 添加联合支持，
我最近对 Mastodon 产生了些许兴趣（足以购买域名，但尚未实际安装 Mastodon），因此我阅读了一些关于使用 Mastodon 对 Discourse 进行身份验证的文章。
我发现有几篇文章暗示这比人们想象的要困难。我记得，似乎有人提供了一笔资助来开发一个插件，但似乎失败了。我大胆猜测这是一个 10,000 美元的问题；如果我猜对了，这正是你需要的倡导类型。
编辑：但我将身份验证与联合混淆了。
---
### Author:  [@sam](https://meta.discourse.org/u/sam)
#### Post date: [2022年十一月28日 22:03 UTC](https://meta.discourse.org/t/federation-support-for-discourse/90921/78 "2022-11-28T22:03:56Z")
我在这里普遍担心的是，这些想法通常非常宏大，很难将其分解成小的部分。
我确实觉得联合（federating）这个想法很有趣。一个可能的具体实现可以是：
- 允许 Discourse 管理员联合一个分类。
- Mastodon 上的用户可以关注它，例如关注：`announcements@meta.discourse.org`
- 当创建新的公告主题时，会联合发布一个新帖子，其中包含摘要和原始链接。
- 当用户在 Discourse 上回复时，新的回复会被联合并归属（作为对原始主题的回复）。
- 当 Fediverse 上的某人回复时，会在主题中创建一个“影子”帖子，归属于 Mastodon 上的发帖人。
至少像这样的东西足够小，可以很好地装进我的脑子里。
---
### Author:  [@aschrijver](https://meta.discourse.org/u/aschrijver)
#### Post date: [2022年十一月28日 22:04 UTC](https://meta.discourse.org/t/federation-support-for-discourse/90921/79 "2022-11-28T22:04:43Z")
ActivityPub 的问题在于，它是一个易于阅读的开放标准，但实现它并不能让你立即“成为 Fediverse 的一部分”。还有很多其他事情需要实现，并且——对于讨论论坛领域来说——需要一个自定义的 ActivityPub 词汇表来进行消息交换。还有其他项目可以“引导”，以及一些可以采用的库，但确实需要一些重大的开发。
在倡导方面……我个人认为，如果做得好，AP 支持可以为产品增加独特的卖点。不必为每个论坛都注册就是一个方面……对我来说也是一个障碍。我需要为了我想发的这一个帖子而注册另一个 Discourse 吗？
但联合可能会带来更大的价值。在我梦想的场景中，我会安装一个个人 Discourse 或注册一个实例，这个实例——就像 Mastodon 一样——一开始会是完全空的。然后，我将根据我的需求和兴趣自己填充社区结构。选择这个主题小组，并将其添加到这个类别下，添加另一个小组。
**更新** ：与 @sam 同步发布 🙂 .. 这是对 @pfaffman 的回应
---
### Author:  [@aschrijver](https://meta.discourse.org/u/aschrijver)
#### Post date: [2022年十一月28日 22:11 UTC](https://meta.discourse.org/t/federation-support-for-discourse/90921/80 "2022-11-28T22:11:13Z")
> [@sam](#):
>
> 至少像那样的小东西可以很好地装进我的脑子里。
是的，那将是一个很好的开始。Lemmy 链接聚合器在某种程度上就是这样工作的，它提供了一个社区的联合。请注意——尽管更广泛地互动将是一个非常好的功能——但一开始联合可以仅在 Discourse 实例/租户之间实现。
并非所有东西都适合 Mastodon……它是一个微博应用程序，不支持 markdown（尽管其他 Fedi 应用程序支持）。
目前正在进一步开发联合 `Groups` 支持。Lemmy 是一个例子。Bonfire 将添加类似 Google+ 的圈子等功能。
---
### Author:  [@mcdanlj](https://meta.discourse.org/u/mcdanlj)
#### Post date: [2022年十一月29日 02:27 UTC](https://meta.discourse.org/t/federation-support-for-discourse/90921/81 "2022-11-29T02:27:42Z")
是的！这就是我希望看到的，也是我希望推广的工作流程。☺
摘录的长度可以方便地进行配置，其中 0 表示整个文章而不是摘录。请注意，Mastodon 的 500 个字符限制是任意的，与 Fediverse、ActivityPub 或 ActivityStream 无关。我目前运行的 Mastodon 节点有 2000 个字符的限制，[social.kernel.org](http://social.kernel.org) 的限制是 31337 个字符。即使是默认的 Mastodon，其用于 \_撰写\_帖子的 500 个字符限制也仍然可以很好地显示较长的帖子。
我看到的一个小困难是，Discourse 中的用户和类别命名空间是分开的，但在 ActivityPub 中是同一个“Actor”，而至少 Mastodon 有一个相当严格的正则表达式来识别 Actor。给定 `#announcements` 类别为 `@announcements@meta.discourse.org`，此评论将作为 `@mcdanlj@meta.discourse.org` 的作者进行联合。
默认情况下，作为 Discourse 管理员，我希望使用类别 slug 作为 Actor 名称。我想，当管理员为类别设置联合时，他们会选择 Actor 名称，该名称将默认为 slug，并且（像组名一样）相对于 Discourse 用户名是唯一的。
（顺便说一句，我以前担心 Mastodon 用于识别 Actor 名称的正则表达式，但我认为它实际上只用于提及用户，这在这里并没有什么价值。所以，即使将 `#documentation:admins` 表示为 `@documentation:admins@meta.discourse.org` 也可以，尽管我肯定想在几个主要的微博客系统上进行测试，包括 Mastodon 和 Pleroma。）
---
### Author:  [@mcdanlj](https://meta.discourse.org/u/mcdanlj)
#### Post date: [2022年十一月30日 00:55 UTC](https://meta.discourse.org/t/federation-support-for-discourse/90921/82 "2022-11-30T00:55:08Z")
从 Mastodon 或 Pleroma 用户的角度来看，这实际上会是这样的：`@announcements@meta.discourse.org` 会 **转发** / **转推** `@sam@meta.discourse.org` 的主题帖子，然后也会转发/转推 `@mcdanlj@meta.discourse.org` 的评论帖子，作为对 OP 的评论 — OP 或评论实际上都不是由类别创建的，而是由一个人在类别中创建的。
也许该插件最初只能为类别 Actor 实现 webfinger（以便能够关注它们），但最终为个人用户实现它可能也有意义。在 Mastodon 上，我可能会合理地想要关注 `@sam@meta.discourse.org` 来查看他的帖子和评论。
---
### Author:  [@Thomas\_Rother](https://meta.discourse.org/u/Thomas_Rother)
#### Post date: [2022年十二月23日 21:04 UTC](https://meta.discourse.org/t/federation-support-for-discourse/90921/83 "2022-12-23T21:04:17Z")
问题：本次讨论的当前状态以及可能的实施计划是什么？您是否需要任何测试支持，例如？或者那个问题是否“为时过早” 😉
[上一頁](https://meta.discourse.org/t/federation-support-for-discourse/90921.md?page=3)
[下一頁](https://meta.discourse.org/t/federation-support-for-discourse/90921.md?page=5)