对我来说，Discourse Chat 相较于其他工具的杀手级功能是能够将消息移动到论坛帖子中。在我们的社区中，这很可能会成为核心社区成员之间进行“严肃”聊天的场所，他们需要能够区分有用信息和无关信息，而像这样组织消息（例如将功能请求分组）的能力恰恰能做到这一点。
我的第一反应是“这在 Discord 上还有很多需要改进的地方”，但现在我认为最明智的做法是发挥其独特性，提供更多有用的组织工具，如上所述。
我们的社区目前使用 Discord，将部分聊天转移到 Discourse 可能会遇到一些阻力，但我认为两者可以并存。Discord 将是我们所有社区成员的第一个接触点，包括随意的“趣味”聊天、语音频道等，而 Discourse 将是核心社区成员更“严肃”的场所。
并且使用 webhook、同步机器人等将是吸引 Discord 社区成员“更深入”地参与到这个更严肃的社区空间的关键，即，将休闲爱好者转化为积极的贡献者。
我很想在这里与其他社区经理聊聊他们是如何考虑将 Discourse Chat 与他们现有的聊天工具结合起来的。也许我们应该将我在这里的消息移到一个新主题中。
我也非常关注 Discourse 聊天将如何与 Discord 相关联，因为许多社区（包括我管理或经常互动的几个社区）似乎同时拥有这两个平台。作为一个曾经不得不适应 Discord、并对其信息快速流动以及由此产生的半丢失的有趣讨论（并非真正被删除，只是很难在 Discord 中找到和“浮现”）感到无奈的人，我最初有一个强烈的冲动，想要将所有东西都从 Discord 迁移出去，并希望 Discourse 聊天能达到与之相当的功能，以实现这一目标。
然而，我认识到其他人有不同于我的偏好和偏见，无论如何，任何强制性的迁移方法可能都不会受欢迎，并且很容易对现有社区造成损害。
出于这些原因，我之前曾讨论过希望更好地集成 Discord 和 Discourse：
总的来说，我对同步（聊天）和异步（论坛等）讨论的界面非常感兴趣。我认为 Discourse 在这里融合这两者的机会最大，因此集成的聊天功能非常令人兴奋。
也许让 Discord 自然过渡到 Discourse 聊天的最佳机会就是让 Discourse 聊天变得非常非常棒。 到目前为止，我对其早期进展印象深刻，但我知道聊天功能还有很多工作要做，而且它可能永远不会成为团队的重点（也许我错了）。我认为，在那些拥有活跃 Discourse 论坛的社区，并且 Discord 不是最初的平台，或者只是因为免费/易于设置而在某个时候被选为实时选项的社区，Discourse 聊天可能会更自然、更容易迁移。
为了更具体一些，这是我目前在两个我管理的社区中处理事情的想法：
这是一个有趣的案例，因为如前所述，它始于 Discord。因此，对于许多社区成员来说，这个空间确实有很大的“引力”。然而，过去几个月，Discord 和 Discourse 的活跃度都很低。我们也遇到过一些显著的问题，即在 Discord 聊天中发生了极其精彩的讨论，但很难将其转移到 Discourse 讨论中（鉴于其深度以及为了日后参考、长期参与等而保存的有用性，它本应属于那里）。已经相当不错的 Discourse 聊天功能，可以将一组消息移动到新主题或现有主题，简直是梦想成真。
因此，虽然这不是我一个人能决定的，但鉴于两个平台的活跃度都较低，我倾向于尝试将主要参与转移到 Discourse 论坛，大量使用聊天功能，论坛主题保留用于更长篇的内容，而两者之间流畅的界面可以使一切更顺畅地运作。但这当然说起来容易做起来难。Discourse 的登录集成或许会有所帮助……
这个社区与一个注重安全/隐私的生产力应用程序相关联，而且许多用户已经抱怨使用 Discord。最初使用 Telegram 部分是出于隐私考虑。然而，坦率地说，Telegram 在管理群组、角色等方面确实很糟糕。这也是开始转向 Discord 的部分原因。现在 Discourse 本身将提供聊天功能，我希望主要的官方聊天频道都可以迁移到论坛实例内部。我认为这将是一个巨大的胜利，因为它将同时解决 Discord 的隐私问题和 Telegram 的管理问题，同时进一步将通信集中到一个更统一、更强大的系统中。这应该能为团队节省大量时间。Discord 和 Telegram 频道很可能会继续存在，团队可能需要找到方法将它们的管理顺利移交给受信任的社区成员，同时明确表示它们不再是官方频道……这只是我个人的希望和设想，并非我一人能决定，但我将倡导这种方法。
因此，在我看来，管理员和用户都有优势，但目前的主要优势在于希望实现集成的管理员。为了推动用户采用，我认为聊天功能需要尽可能强大和易于使用。我确实预计，至少在一个社区中说服用户迁移过来会有些困难。
所以，我没有特别有见地的答案。只是在思考这一切。但我想为这个讨论做出贡献并鼓励它，因为我也非常想知道人们将如何处理这个问题，以及他们认为哪些资源、功能等最能有效地帮助他们做到这一点。
关于这个话题，我们在 Discord 中使用了一些机器人，例如 Carlbot，它可以通过触发器响应关键词。您预计是否可以在 Discourse Chat 中复制这些机器人？
我们可以构建任何东西 
但我们还没有在内部讨论过。
太棒了！如果核心团队提供一个插件框架，让我们可以在 Discourse 中构建类似的机器人，我认为这就足够了。
当然，这在发布时并不是优先事项。
Discord 机器人是托管在别处，对吧？由于 Discourse 有一个开放的 REST API，Discord 的一切都可以开箱即用。
使用 Discourse，您可以获得额外的优势，因为您可以将其制作成在同一服务器中运行的 Discourse 插件，
甚至是一个轻量级且安全的 #theme-component。
不过，作为一个围绕 Discourse 发展生态系统的途径，机器人 API 可能会很有趣。
Falco说得对。我们已经有办法通过聊天管理员界面来设置机器人了。
那是用于 webhook，对吧？但 Discourse 在这方面可以比 Discord 强大得多
您可以为 chatSent 和 chatReceived 创建一些 appEvents，然后人们就可以使用 js 主题组件来装饰消息。这将为我们提供“无服务器机器人”
Discourse开源让我觉得机器人（bots）的潜力要大得多
我们的团队愿意投入资源来根据社区的需要开发我们自己的机器人/插件，但这在Discourse这样的开源框架中更具吸引力
而且我们已经为Discord使用了一些机器人，所以我一直在考虑将它们移植到Discourse的难度
我对技术不太了解，所以不确定Discourse的API需要做多少工作才能支持与频道交互的机器人
与Discord相比，Discourse的独特功能也为Discourse机器人带来了令人兴奋的可能性。例如，想象一个机器人可以监听聊天中的关键问题，然后自动将它们移到一个主题帖中，并将问题分配给支持人员。
很棒的提议，Falco；这相当令人兴奋，而且是我没想过的。
哦，这真是个很棒的主意。
完全有可能。就像 Falco 说过的，我们可以在 5 分钟内从我们这边支持它。
许多 Discord 机器人依赖于它们自己的角色系统。我假设我们可以使用 Discourse 群组来复制这一点。
Discord 中一个非常流行的用例是拥有一个带有表情符号的欢迎频道，人们可以点击这些表情符号来为自己分配一个角色。要在 Discourse 中复制这一点，我想我们可以有一个欢迎主题，指示人们点击表情符号（现在我们有了 Discourse Reactions，这更加可行），然后让机器人/插件根据这些反应将他们分配到群组。
然后，我们可以像在这里一样提及群组 Allow groups to be mentioned and sent messages
我认为突出这种并行功能将是吸引那些更深层次地融入 Discord 生态系统的社区的关键。
另一个并行功能是添加 此功能，按群组对在线用户进行分组，就像 Discord 按角色分组一样。
虽然我可以看到吸引 Discord 用户营销方面的考量，但这种“通过表情符号反应来获取角色”实际上是 Discord 功能不足的一种笨拙的解决方法，特别是因为它没有更好的请求和管理组成员身份的方法。Discourse 已经有各种选项，如“允许用户自由加入群组”与“允许用户请求加入”，以及一套完整的管理员工具。因此，应该有可能以更好的方式来处理这个问题，我更希望 不 看到基于表情符号的组成员身份，至少是开箱即用的。不过，这可以成为一个很棒的插件。 
因此，我们多年来一直在深入思考这个用例。你在 Discord 中必须编写机器人的原因是因为你有点像在“削足适履”，并且会产生这种奇怪的用户体验，因为没有更好的方法。
在 Discourse 中，你将能够配置 Discourse Automation 来实现相同的用例，并且能够以对你的用户更有意义的方式（例如在投票中投票或在聊天中回复消息）来获取群组/角色分配。