![]() ![]() History of messages can be stored by ejabberd however, but for a recipient to get the history he will need to join the MUC. Those are only sent to people CURRENTLY in the chatroom. This is not how ejabberd handles MUC messages. Therefore if a recipient is offline, ejabberd will store this message as any other regular message. When a user sends a message, he actually publishes on the node, and ejabberd will send the message to all subscribers as if it were a regular message (except it comes from ). For the pubsub node, you need to set an option to allow any subscriber to post. ![]() You need to be familiar with both concepts. Everything else is handled by the pubsub node.Įssentially when the user wants to create a groupchat, our app creates a pubsub node as well as a MUC. The only purposes of the MUC are to hold the list of participants as well as the name of the groupchat. This way the list of the groupchat participants can be retrieved by checking the list of owners of the MUC. So when my app creates a groupchat, it creates a pubsub node for messages, invite all participants to subscribe (including self) to the pubsub and my app also creates a MUC and makes every participant an owner of that MUC. One issue I had with pubsub over MUC though is that it is hard to get the list of subscribers. When the user reconnects, he gets all the offline messages including the pubsub messages which are sent as normal messages - that is it. Using pubsub will force the server to store offline message per recipient. What I wanted is for the server to save offline messages by recipient, and for the recipient to get all MUC messages when he gets online (without having to join each MUC). And I did not want to retrieve MUC history which requires the user to rejoin every MUC to update his messages database. I faced the same problem of MUC not storing offline messages for each recipient. I faced your issue as I sought to implement groupchats for my chatting app. The downside is that I doubt such a multicast service is supported out of the box in ejabberd, and it seems like that extension leaves much details about how it could be implemented unspecified. The upside is that offline storage is there again. ![]() Basically it allows a client to use a special multicast service to send their message to multiple recipients at once. There's another possibility which you might explore: "multicast addressing" of XEP-0033 ("Extended stanza addressing"). Then the room supports querying these messages by the joined users. In a sense, instead of storing offline message for each user, the room might be configured to store just a certain number of the most recent messages sent to it (or all such messages for a given period of time). So what you really want is "room history"-a part of the XMPP-0045 extension which allows the client to explicitly ask the room for the message history they missed. This is in fact the most important reason for not supporting offline storage.Īs you can see, XMPP MUC rooms are much like IRC chats on steroids. MUC rooms are by definition transient: when a user is offline, they're not in any room- (re-)joninig a room is an explicit action. Obviously, this is another reason why such an idea of "MUC room offline storage" has no sense. MUC rooms are not "local server only": a potentially unbound number of users from any number of other servers might join the room, and messages to those users will be delivered by routing them via their respective servers. (Well, if this would be the only problem, it could possibly work for members-only rooms, I must admit.) So exactly for which users not currently present in the MUC room should the server store the messages in the offline storage? I mean, in the generic case, the server does not know all the users who could ever possibly chat in a given room it hosts. Potentially unbound number of participants might be present in a room at any given time. In fact, if you'll think about this a bit more you'll understand why: That's because there's no such concept for multi-user chat rooms.
0 Comments
Leave a Reply. |