你好，Nathan。
我们已经在 AWS 上提供澳大利亚的托管服务，但由于目前需求不高，将这些地区的托管服务（colocated hosting）纳入我们的路线图目前不在计划内。您更倾向于本地托管而不是美国或欧盟托管，是否有特别的原因？
呵呵，全球分布式的一个棘手之处在于，很难确定此类活动的优先地点。但我很好奇——什么样的活动能带来足够的价值，让您愿意为此前往悉尼？
5 个赞
我理解您对这个问题的担忧，是的，我们确实提供了保证：
在 Discourse ID 的常见问题解答 (FAQ) 底部：https://id.discourse.com/faq，我们链接到我们的隐私政策：
https://www.discourse.org/privacy
其中涵盖了这个问题：
CDCK 会出售我的个人信息或与他人共享以提供行为广告吗？
不，CDCK 不会出售个人信息，也不会与第三方共享个人信息以用于跨上下文行为广告。
Jeff 正在世界各地活动，您可以在以下地址关注他：https://infosec.exchange/@codinghorror
这是一个难题，我们每年团队聚会时能在线下见面的时光对我来说非常珍贵。
6 个赞
您好！
我对这个话题非常感兴趣，很高兴您提到了它。我写了关于我的预测的详细内容在这里，以及我认为社区建设者应该思考的内容在这里，而 Mae 在这里分享了关于如何优化社区内容以实现人工智能发现的建议。
我们花了很多时间思考如何更好地支持 Discourse 社区，以便在如何利用（和保护）他们的数据方面做出灵活的选择。
目前我们对 Discourse MCP 感到非常兴奋，您可以这里关注未来的创新。
7 个赞
嗨，不公平，这是一个问题里包含三个问题 
launcher 2 工作的一部分是发布预构建的 Docker 镜像，所以是的，我们有计划，而且你已经可以在测试版中尝试了 
关于主题中每个用户的存储。这是我一直想构建的一个领域，已经很长时间了。我多年来和 @david 讨论过这个问题很多次。这里最大的担忧之一是确保有适当的限制。我们不希望一个糟糕的主题消耗服务器端数 TB 的存储空间。找到合适的范围很难。我刚刚和 GitHub helper 一起集思广益。见：https://meta.discourse.org/discourse-ai/ai-bot/shared-ai-conversations/OjpV557puqmyvwFkEIcUvA
我喜欢 API 的想法，可以有选择地允许“预加载”，这对主题开发者来说可能是改变游戏规则的。
开源是 Discourse 的基因。我们一直希望有一个开源的替代品来对抗那些不幸占据主导地位的庞大的闭源孤岛。我们希望我们的代码能够长久地存在下去，并将由我们托管或自托管的 Discourse 实例视为积极的。
开源的性质使 Discourse 比许多其他替代品更安全，因为人们会审计代码，它允许平台以奇特而美妙的方式进行扩展。
我们喜欢与开源社区和 meta 上的优秀贡献者互动
6 个赞
我也很喜欢这个问题，Jen。我有一些想法，其中一些我在这里分享了。我认为聪明的社区建设者会认识到，他们在管理内容的分发和消费方面确实扮演着重要的角色。我怀疑这在你们的成员主导的治理结构下可能具有挑战性。这可以实现——这里有一个案例研究，其中一个社区能够在众包治理下有效地扩展沟通，但他们从一开始就对其进行了战略性管理。
5 个赞
您好！(我这里是晚上11点 ). 感谢您的这篇 https://blog.discourse.org/2025/11/how-discourse-uses-discourse/，我立刻分享给了我的同事们。今天，其中一位同事在阅读了这篇博文后问我：
“我们为什么不使用 Discourse 聊天（Discourse Chat），就像他们那样呢？”
（我们使用 Discord，这让大多数人抓狂，因为我们选择的两个通信平台是 Discourse 和 Discord 
）
所以我的回答是：
“基本上是因为缺少推送通知，尤其是在自托管（self-hosted）环境中。”
然后我想，也许 Discourse 可以像他们处理 Discourse ID 那样，在推送通知方面做些什么？接着我又想，这可能会危及他们托管服务的附加价值……但也许这对其他人来说仍然是一个有趣的问题？
4 个赞
在我博客上，我稍微警告过可能的缺点。所以这是一个始终需要谨慎对待的领域。
话虽如此，现在还处于早期阶段，但我强烈建议您尝试（并关注）Discourse Vibe 的发展：
人工智能代理正在以惊人的速度发展，我们正在确保 Discourse 能够提供最佳的上下文和工具，以便代理能够很好地完成工作。
例如，我们最近完成了帮助代理进行适当的构建-测试-构建-测试循环所需的工具三件套。
bin/rspec FILENAME 运行任何 RSpec 测试
bin/lint FILENAME 检查任何文件的代码风格（较新）
bin/qunit FILENAME 运行任何 QUnit 测试（新）
除此之外，我们现在还提供 Discourse MCP，使代理可以轻松生成测试数据并进行手动测试。
关于“人工智能为我进行 UI 更改”的主题
我一直在试验 dv config theme 来帮助启动一个用于构建主题的沙盒，但这还处于早期阶段。我希望它能发展到可以进行简单主题脚手架的程度。
我当然看到了一个未来，自助客户可以只指向一个网站，然后说：“嘿，这是我的网站，让论坛看起来更像它一点。”
令人兴奋的时代即将来临。
4 个赞
搜索是随着大型语言模型（LLM）变得更便宜、更快而将发生巨大变化的领域之一。
将 LLM 放在关键路径上可能会有点棘手，因为搜索将不再是即时的。
话虽如此，人们愿意等待一段时间以获得出色的结果，正如 ask.discourse.com 所证明的那样。
关于“更快更好的搜索”这个话题，我确实看到了将 BM-25 引入 Discourse 的方法，以及如何利用 LLM 预先注入概念以处理一些奇怪和美妙的拼写问题（这样您在搜索时就不会调用它们，而是进行预处理）。
我们的路线图中没有具体内容，但更快更好的搜索是我们一直追求的目标。
5 个赞
这仍然处于“我们正在试验”阶段。
我们资助了 @angus 完成了大量工作。@pmusaraj 一直在仔细测试进展情况。
这个插件现在功能非常强大，我希望看到它得到更广泛的应用，并希望听到社区对它的未来有什么好的想法。
我想这个问题又回到了你那里，你最大的不足是什么？
6 个赞
S3 兼容性总是伴随着某种程度的妥协，它真的 S3 兼容吗？例如，它是否支持签名直接上传、相同的生命周期策略 XML，等等等等。
我们努力确保基本功能正常工作，但这可能是一场艰苦的战斗，因为有太多的“兼容”S3 提供商提供不同级别的兼容性。
不过，代理和 CDN 是一流的功能，它们的配置可能会很棘手（尤其是代理），因为你需要以安全的方式传递 IP 地址，而且调试可能很困难。
3 个赞
这当然是我们可能会考虑增加的附加价值，以使 Discourse ID 更具吸引力。其中一部分是协议挑战，尤其是在第三方网站上。
我们不想存储任何私有论坛数据，所以也许可以使用某种协议来说：“嘿，您在网站 X 上有新通知”，然后让应用程序从网站 X 查找通知。或者使用某种形式的端到端加密。
这是一个棘手的技术问题。
话虽如此，Discourse PWA 已经在 iOS 和 Android 上支持推送通知。
5 个赞
而这一个对你们两位来说更私人一些：
在经营公司时，对你们来说最困难的部分是什么？又是如何克服的？
谢谢 
3 个赞
以健康和有韧性的方式驾驭增长真的非常困难。我们的许多系统和流程都是随着业务的增长而自然形成的。当我们只有 14 个人（就像我刚开始时一样）时，用电子表格和电子邮件处理所有事情是可行的。我们几乎没有需要处理的繁文缛节或官僚主义。我们可以快速行事。
随着您的发展，您需要更强大的框架，这涉及到流程。有些人比其他人更难适应这种变化。一个很好的例子是子公司化。我们最近在荷兰设立了 CDCK.BV，以雇佣我们所有的欧盟人员。这引入了我们以前不必处理的巨大复杂性。
同样，在完全远程、异步优先的环境中扩大沟通规模也具有挑战性。保持信号与噪声的比率适当调整变得越来越困难。
在一个尚未为我们工作的方式做好准备的世界中找到解决挑战的方法是困难的。我不认为我们已经克服了它，但我们肯定在努力推动变革。
10 个赞
非常抱歉，我很难回答这个问题。
我想，如果我稍微回顾一下，5 年前我期望 Discourse 能成为一个更好的社区平台，而它确实做到了。
我希望在 5 年后，我们能成为一个更优秀的社区平台，与时俱进，为人们聚集和分享有趣段落创造无数有意义的线上空间
12 个赞
就这样结束了！感谢所有参与者，我们非常喜欢这些问题。
6 个赞
感谢