实际上，我们正在使用ejabberd服务器为我们的客户端的聊天应用程序之一。一切正常，除了群聊。
我们正在使用MUC进行群聊，但当用户离线时，它不会向成员发送消息。是否有其他插件或其他东西，我们可以使其工作?
或者任何人都可以建议如何从群组聊天记录中接收该用户的离线消息。
提前感谢
这是因为多用户聊天室没有这样的概念。事实上，如果你再多思考一下，你就会明白为什么:
-
在任何给定时间，房间中可能存在未绑定的参与者数量。
那么，对于哪些用户当前不在MUC房间中的，服务器应该将消息存储在脱机存储中?我的意思是，在一般情况下，服务器不知道所有可能在它托管的给定房间里聊天的用户。(嗯，如果这是唯一的问题，我必须承认，它可能适用于会员制房间。)
-
MUC房间不是"仅限本地服务器":来自任何数量的其他服务器的潜在未绑定数量的用户可能会加入房间，并且消息将通过他们各自的服务器路由传递给这些用户。
显然，这也是为什么这种"MUC房间离线存储"的想法没有意义的另一个原因。
-
根据定义，MUC房间是瞬时的:当用户离线时，他们不在任何房间—(重新)连接一个房间是一个明确的动作。
正如您所看到的，XMPP MUC聊天室非常像IRC聊天。
所以你真正想要的是"房间历史"— XMPP-0045扩展的一部分，它允许客户端显式地向房间询问他们错过的消息历史。从某种意义上说，可以将房间配置为仅存储发送到它的一定数量的最新消息(或给定时间段内的所有此类消息)，而不是为每个用户存储脱机消息。然后，房间支持由加入的用户查询这些消息。
你可以探索另一种可能性:XEP-0033的"多播寻址"("扩展节寻址")。基本上，它允许客户端使用特殊的多播服务，一次将消息发送给多个接收者。好处是离线存储又出现了。缺点是我怀疑ejabberd中是否支持开箱即用的多播服务，而且似乎扩展对如何实现它留下了许多未指定的细节。
当我试图为我的聊天应用程序实现群聊时，我遇到了您的问题。我面临着MUC不为每个收件人存储离线消息的相同问题。而且我不想检索MUC历史记录，因为这需要用户重新加入每个MUC来更新他的消息数据库。我想要的是让服务器按收件人保存脱机消息，并让收件人在联机时获得所有MUC消息(无需加入每个MUC)。
我的方法是通过pubsub。使用pubsub将强制服务器为每个收件人存储脱机消息。当用户重新连接时，他将获得所有脱机消息，包括作为正常消息发送的pubsub消息——仅此而已。我对MUC的pubsub有一个问题，那就是很难获得订阅者列表。因此，当我的应用程序创建群聊时，它为消息创建了一个pubsub节点，邀请所有参与者订阅(包括self)到pubsub，我的应用程序还创建了一个MUC，并使每个参与者都成为该MUC的所有者。通过这种方式，可以通过检查MUC的所有者列表来检索群聊参与者列表。MUC的唯一用途是保存参与者列表以及群聊的名称。其他一切都由pubsub节点处理。
有不清楚的地方请告诉我。
额外的细节:本质上，当用户想要创建群聊时，我们的应用程序会创建一个pubsub节点以及一个MUC。您需要熟悉这两个概念。对于pubsub节点，您需要设置一个选项以允许任何订阅者发布。当用户发送消息时，他实际上在节点上发布消息，ejabberd将把消息发送给所有订阅者，就像它是一条常规消息一样(除了它来自pubsub.yourdomain.com)。因此，如果收件人处于脱机状态，ejabberd将把此消息存储为任何其他常规消息。
ejabberd不是这样处理MUC消息的。这些只发送给当前在聊天室的人。但是，消息的历史记录可以通过ejabberd存储，但是对于接收方来说，他需要加入MUC才能获得历史记录。这意味着每次应用程序重新连接时，它都必须加入用户现有的所有muc。我们发现这是不实际的。
我们也对同一个群聊使用MUC，但这只是为了存储参与者，以便用户可以随时获得列表(使用pubsub无法做到这一点)。
与MUC相比，使用pubsub的另一个好处是ejabberd存储pubsub数据的方式更有效。我没有深入研究过这个问题，但我希望pubsub能有更好的表现。
新ejabberd服务器16.09版本对多用户聊天进行了改进- MUC Sub:
MUC Sub的目标是尽可能多地依赖现有的MUC规范，同时进行尽可能小的更改，使移动组会话客户端变得容易。
默认开启该特性。要使用它，只需确保在要使用它的房间中设置新参数"允许订阅"。
这里是文档链接:https://docs.ejabberd.im/developer/proposed-extensions/muc-sub/
更多信息在这里:https://blog.process-one.net/xmpp-mobile-groupchat-introducing-muc-subscription/