是的，但这将是一个广泛且昂贵的插件。
1 个赞
使用 SSO 或 LDAP 是否可以允许双向登录，而无需将所有人都迁移到单一域登录？
例如，我有论坛 A、B 和 C。我希望论坛 A 的成员能够使用其论坛 A 的凭据登录并发布到论坛 B 和 C。注册了论坛 B 和 C 的成员也应该能够做到这一点。
我认为此帖及后续帖子应移至自己的主题，因为它们涉及此处讨论的功能的一个子集。
1 个赞
Setup DiscourseConnect - Official Single-Sign-On for Discourse (sso) - Integrations - Discourse Meta 可能会对您有所帮助 
1 个赞
理论上，除了制作一个充当 ActivityPub 联合协议服务器的 Discourse 插件之外，另一种可能性是设置单独的 ActivityPub 服务器上的账户，该服务器支持_客户端_社交 API 协议，并让 Discourse 插件与该服务器通信客户端协议，而不是充当 ActivityPub 服务器。这可能有利于更紧密地集成到现有的 ActivityPub 节点中。但我不认为它比服务器协议更容易实现，而且对于论坛运营商来说，它比充当联合协议服务器需要更多手动设置工作。
在我设想的实现方案中，为了允许用户交互的可能性，必须有一种方法来区分 discourse 用户参与者和 discourse 系统参与者（例如，类别）。我可以想象 @#slug@discourse.example.org 将是一个类别参与者，为稍后添加 @username@discourse.example.org 用户参与者留出空间。但考虑到标签的普遍性，这可能在实践中行不通。
更简单的做法是，只关注第 1-3 点，认为第 4-5 点接近于试图将 Discourse 转变为通用 ActivityPub 服务器，但这绝对不是目的。
2 个赞
Mastodon 使用以下正则表达式进行验证：
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 设置，并且可能会经常配置错误。也许不值得这样做。
1 个赞
也许与其他平台建立联合体没有意义，而是应该在所有 Discourse 实例之间建立联合体，因为 Discourse 实例的数量非常庞大。
2 个赞
这里肯定有巨大的潜力。可能性和可行性值得认真、审慎地考虑。
这可能是“香格里拉”的领域……（阅读上面 Jeff 的帖子 Jeff’s post above 并关注其中的链接。） 如此广泛的集成可能也是大多数 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 曾短暂地带来过很高的希望，因为它最初是为内部业务开发的（并且有一个非常有趣的起源故事)，但甚至没有通过第一轮筛选。我对 Discourse 印象深刻，并对其充满乐观。
1 个赞
这正是本主题的重点，即在 Discourse 实例之间。
在 OP 中已说明：
2 个赞
好的，还有
还有
“一个微型联盟的网站将是一个促进”
都在主题内，对吧？ 
不一定需要。还需要考虑插件生态系统。
规模较大的功能通常会作为插件甚至主题组件（在可能的情况下）进行开发，这些功能不需要行政开销或集中规划。
这正是 Discourse 生态系统的魅力所在。
例如，Pavilion 在未与 CDCK 协商的情况下创建了 Locations、Topic List Previews、Multilingual、Follow、Layouts、Custom Wizard（仅举几例）。因此，部分原因是我们参与了这次讨论。
7 个赞
愿上帝保佑我们的插件开发者！他们慷慨地提供可供现场测试并考虑纳入核心产品的概念验证示例。您的多语言插件就是一个绝佳的例子！
在 python.org，这个角色由库开发者扮演，他们有时会创建“必须拥有”的功能，这些功能会被接受并纳入 Python 核心包或标准分发库。
2 个赞
我一直在论坛的多个主题中倡导 Discourse 添加联合支持，例如 此处。随着 Fediverse 如今成为主流，Tumblr 以及可能的 Flickr 等也添加了联合支持，问题是 Discourse 是否有更大的兴趣添加支持。
Flarum 的核心开发者联系我，就 AP 实现提供建议，我将一些链接发回，其中包括刚才提到的那个。
PS. 在 SocialHub Discourse 论坛（Fediverse 的开发者社区）上，我们长期以来一直在寻找如何成为 Fediverse 的一部分，因为独立的论坛对大多数人来说参与门槛太高了。
7 个赞
我最近对 Mastodon 产生了些许兴趣（足以购买域名，但尚未实际安装 Mastodon），因此我阅读了一些关于使用 Mastodon 对 Discourse 进行身份验证的文章。
我发现有几篇文章暗示这比人们想象的要困难。我记得，似乎有人提供了一笔资助来开发一个插件，但似乎失败了。我大胆猜测这是一个 10,000 美元的问题；如果我猜对了，这正是你需要的倡导类型。
编辑：但我将身份验证与联合混淆了。
1 个赞
我在这里普遍担心的是，这些想法通常非常宏大，很难将其分解成小的部分。
我确实觉得联合（federating）这个想法很有趣。一个可能的具体实现可以是：
- 允许 Discourse 管理员联合一个分类。
- Mastodon 上的用户可以关注它，例如关注：
announcements@meta.discourse.org - 当创建新的公告主题时，会联合发布一个新帖子，其中包含摘要和原始链接。
- 当用户在 Discourse 上回复时，新的回复会被联合并归属（作为对原始主题的回复）。
- 当 Fediverse 上的某人回复时，会在主题中创建一个“影子”帖子，归属于 Mastodon 上的发帖人。
至少像这样的东西足够小，可以很好地装进我的脑子里。
13 个赞
ActivityPub 的问题在于，它是一个易于阅读的开放标准，但实现它并不能让你立即“成为 Fediverse 的一部分”。还有很多其他事情需要实现，并且——对于讨论论坛领域来说——需要一个自定义的 ActivityPub 词汇表来进行消息交换。还有其他项目可以“引导”，以及一些可以采用的库，但确实需要一些重大的开发。
在倡导方面……我个人认为，如果做得好，AP 支持可以为产品增加独特的卖点。不必为每个论坛都注册就是一个方面……对我来说也是一个障碍。我需要为了我想发的这一个帖子而注册另一个 Discourse 吗？
但联合可能会带来更大的价值。在我梦想的场景中，我会安装一个个人 Discourse 或注册一个实例，这个实例——就像 Mastodon 一样——一开始会是完全空的。然后，我将根据我的需求和兴趣自己填充社区结构。选择这个主题小组，并将其添加到这个类别下，添加另一个小组。
5 个赞
是的，那将是一个很好的开始。Lemmy 链接聚合器在某种程度上就是这样工作的，它提供了一个社区的联合。请注意——尽管更广泛地互动将是一个非常好的功能——但一开始联合可以仅在 Discourse 实例/租户之间实现。
并非所有东西都适合 Mastodon……它是一个微博应用程序，不支持 markdown（尽管其他 Fedi 应用程序支持）。
目前正在进一步开发联合 Groups 支持。Lemmy 是一个例子。Bonfire 将添加类似 Google+ 的圈子等功能。
3 个赞
是的！这就是我希望看到的，也是我希望推广的工作流程。
摘录的长度可以方便地进行配置，其中 0 表示整个文章而不是摘录。请注意，Mastodon 的 500 个字符限制是任意的，与 Fediverse、ActivityPub 或 ActivityStream 无关。我目前运行的 Mastodon 节点有 2000 个字符的限制，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。）
3 个赞
从 Mastodon 或 Pleroma 用户的角度来看，这实际上会是这样的：@announcements@meta.discourse.org 会 转发 / 转推 @sam@meta.discourse.org 的主题帖子，然后也会转发/转推 @mcdanlj@meta.discourse.org 的评论帖子，作为对 OP 的评论 — OP 或评论实际上都不是由类别创建的，而是由一个人在类别中创建的。
也许该插件最初只能为类别 Actor 实现 webfinger（以便能够关注它们），但最终为个人用户实现它可能也有意义。在 Mastodon 上，我可能会合理地想要关注 @sam@meta.discourse.org 来查看他的帖子和评论。
2 个赞
问题：本次讨论的当前状态以及可能的实施计划是什么？您是否需要任何测试支持，例如？或者那个问题是否“为时过早” 