ejabberd MUC 和 MUC/Sub - 澄清答案

【问题标题】：ejabberd MUC and MUC/Sub - Clarificationejabberd MUC 和 MUC/Sub - 澄清
【发布时间】：2016-12-09 10:50:51
【问题描述】：

我最近一直在使用 ejabberd 中的新 MUC-Sub 模块 - 用例是我需要在我的移动应用程序中拥有类似 WhatsApp 的永久房间。在我进一步使用 MUC/Sub 之前，请一位 ejabberd 专家对以下概念发表意见吗？可能是我缺乏对 ejabberd 的全面了解，因此是基本问题。否则请让我知道一个开始更好地理解以下内容的好地方......我确实已经详细研究了这两个链接（https://blog.process-one.net/xmpp-mobile-groupchat-introducing-muc-subscription/ 和 https://docs.ejabberd.im/developer/proposed-extensions/muc-sub/）。谢谢！

本质上，如果我们需要一个 MUC 房间在所有用户下线时停止被破坏，我们是否不能简单地禁用该功能 - 以便即使参与者离开或房间空无一人，服务也能继续运行。该服务仍然可以继续指向加入房间的原始房间参与者，并且如果房间中有消息发送，该消息将在每个参与者的流中排队。如果参与者离线，消息将进入他/她的离线消息列表（而不是 MUC-Sub 当前使用的存档/MAM）。为什么我们需要依赖 Pub-Sub 和 MAM 模型，如果这个问题可以通过简单地保留房间中参与者的参考（即使在他/她离线之后）然后利用 mod_offline 模块（这应该发生）来解决自动）。

我确信这里有一个根本原因可以忽略，但如果有人能提供一些启发，我将不胜感激！

【问题讨论】：

标签： xmpp publish-subscribe ejabberd

【解决方案1】：

正如博客文章所解释的，这与保持聊天室是否活跃无关。用户在离线或重新连接时无法收到推送，如果他们没有再次加入，这是因为 MUC 是基于存在的。不在房间内的用户不是房间的居住者，也不应该收到任何东西。

我建议您再次仔细阅读XEP-0045 MUC 和MUC Sub blog post。 MUC Sub解决的问题应该更明显了。

如果你这样做，你会注意到 XEP-0045 定义了持久 MUC 的概念：

永久房间如果最后一个住户离开，房间不会被破坏；反义词：临时房间。

ejabberd 中的默认设置是在用户加入时将房间创建为临时的，但可以更改房间的设置以使其成为持久性。在这种情况下，当最后一个居住者离开时，它不会被破坏。您需要更改房间配置选项（与您在该房间启用 MUC Sub 的表单相同）。

您通常希望将此房间选项与启用 MUC Sub 结合起来，以便 MUC 房间即使没有用户在场，也可以保留。

【讨论】：

感谢@Mickael - 感谢您在此处和 GitHub 上的回复。我将进一步挖掘这些点，但我在 GitHub 问题上的观点略有不同——即使我将房间设为持久并允许 MUC 订阅，如果用户重新加入房间，他/她的存在仍显示为 none 而不是参与者/主持人。
嗨@Mickaël Rémond，我阅读了 MUC sub 的博文和草稿。是不是这样，对于 MUC Sub，它的整个想法是用户加入房间，而不是订阅它？（假设房间是持久的）？在博客文章中提到，一旦用户上线，重新加入房间会非常耗费网络。那么我是否正确理解不再需要它？在此先感谢并抱歉劫持此线程:)
另一个问题，最新的 ejabberd 实现了哪个草案 xmpp.org/extensions/xep-0369.html 或您自己的 docs.ejabberd.im/developer/proposed-extensions/muc-sub ？我注意到他们有不同的节。
ejabberd 实现了 MIX 和 MUC Sub，但它们是不同的替代方式或处理群聊。