我才刚跟上这个帖子——但我当然认为答案是肯定的 
由于我们企业社区的成功（无论是在用户中，还是在我们公司内部），我们的文档团队联系我们，询问我们是否可以为 documentation.sailpoint.com 构建一个评论系统。从目前来看，我们至少能够实现我们想要完成的几乎所有事情：
从那里开始，文档团队（和我的团队）想要的一切都在 Discourse 中，使我们能够有效地将此体验与我们其他的“日常”论坛使用区分开来，同时仍然让人们能够评论、接收回复通知等。
我当然希望看到这里提到的许多功能得以实现！
目标是允许用户在 https://documentation.sailpoint.com/ 上创建评论，还是您乐于将评论嵌入到文档网站中，让用户访问您的 Discourse 网站来评论文章？
前者是我期望并非常希望拥有的功能（请CDCK开发），但后者至少满足了我们的最低要求。
我实际上将在不久的将来探索一个想法，让Discourse提供我们的markdown文档（不是在主题中，而是在传统的markdown风格文档中），在这种情况下，评论以及注册发表评论将是全包的。但这项探索尚未开始。
我目前正在研究的方法，在技术上可以允许 Discourse 评论直接在 MkDocs 页面上生成，但这需要使用服务器端框架（Remix、Rails 等）来提供 MkDocs 页面。这将使得在文档站点上对用户进行身份验证（使用 DiscourseConnect）成为可能，并且还可以使用内存数据库来缓存之前返回的评论。
（编辑：需要说明的是，我指的是使用 Discourse 作为网站的身份提供者，而不是网站作为 Discourse 的身份提供者。后一种方法是可行的，但对于大多数用例来说过于不灵活。）
不过，要求您的团队做出这样的重大改变可能有些困难。
我确信从您的角度来看，如果这一切都在 Discourse 内部完成会更直接，但也可以将 Discourse 用作内容管理系统。在这种情况下，markdown 文档将作为常规的 Discourse 主题生成。Discourse Webhooks 将用于触发在外部站点上生成文档页面。这实际上是我正在设置的 Discourse 评论演示站点所基于的。
我喜欢这个平台就是因为这一点：它为实现这些（或两者兼有！）目标奠定了所有基础。
鉴于此主题今天已被链接，我想我应该根据我研究这个想法后得出的结论来更新它。
我仍然认为 Discourse 是一个很好的评论平台，原因在我最初的帖子中已经阐述。
关于如何实现这一点，我认为工作应该在 Discourse 端完成——最好是通过改进 Discourse 的评论嵌入脚本。这可以逐步完成。
通过在 Discourse 客户端（例如 WP Discourse 插件）上完成所有工作，技术上可以实现将 Discourse 用作评论平台的服务器，但由于需要在客户端和 Discourse 之间管理状态以及绕过速率限制问题，这变成了一个复杂的问题。这肯定比我愿意负责维护的任何事情都复杂。
此主题中的一些帖子表明，人们有兴趣仅仅允许用户在博客网站上_创建_ Discourse 评论。从我的角度来看，这不是一个很好的解决方案，但现在可以通过 Discourse API 实现。复杂之处在于尝试创建一个完整的评论系统，让用户能够以类似于他们在典型主流新闻网站上与评论互动的方式，在网站上与 Discourse 评论进行互动。
这里正在开发一个 Drupal 集成模块，您可以通过 API 在 Drupal 端撰写 Discourse 评论。
https://www.drupal.org/project/discourse_comments_plus
鉴于我在 ActivityPub 和 WP Discourse 方面的经验，我认为通过嵌入式 JavaScript 实现双向评论是可行的。嵌入脚本将包含以下内容：
如果有足够的预算，我认为我可以在 6-8 个月内完成 v1 的生产准备并与 discourse/discourse 集成。在初始发布之后，我可以做以下事情：
尝试以一种对非技术用户有意义的方式来实现它。现有的平台，如 Disqus 和 Facebook 评论，可能提供了很好的例子。
更多身份验证选项：
我不愿纯粹在客户端开发，是因为考虑到了系统在任何规模下运行的问题。本质上，我不得不排队处理 API 请求并处理来自排队请求的响应。我认为它不够健壮，无法处理例如 1000 个并发用户。通过 JavaScript 嵌入方法，我会有类似的担忧，但原因不同。我怀疑这比尝试在客户端同步所有内容要容易得多。
感谢您的反馈 
昨天我对此进行了更深入的思考，因为该主题被顶上来了（这就是我最终在这里发帖的原因）。我认为仅客户端的解决方案（即 JavaScript 嵌入）是唯一真正合理的解决方案。否则，我们实际上是在讨论许多特定于平台的实现，每个实现都有自己的一系列问题。
您说得对，并发和负载是问题。ActivityPub 在并发和负载方面存在严重问题，因为单个 ActivityPub 帖子可能会为您带来来自 Fediverse 的大量传入和传出请求。在这种情况下，这实际上可能稍微容易一些，因为远程客户端是受控的。此外，在这种情况下，并发和负载实际上只在服务器端（即 Discourse 端）存在问题，尽管它们确实是问题，但我认为可以通过后台作业、缓存和互斥锁来解决。但是的，这些是需要考虑的重要问题。
坦白说，我最大的担忧是时机。
Composer v2 即将推出，在这个时候开始这项冒险却不利用我们新的 composer 将是疯狂的，但我们需要大量前期工作才能在轻量级应用程序中使用它。
我认为在这里应该做的就是关注新的 composer 大约 2-3 个月，然后重新讨论这个问题。
我认为可以并行处理。您需要对讨论进行 2 处更改。
“回复”按钮应向未注册用户显示。
当未注册用户单击此按钮时，应显示此内容：
接下来，您需要弄清楚如何使用评论插入。这些很可能是小的代码更改，而不是大量工作。
我想知道在 Composer v2 发布后，是否还有兴趣开发此功能。我仍然希望看到并使用它。
