Persistent XMPP MUC (XEP-45), like WhatsApp groupchats

Question

From the spec —

7.14 Exiting a Room

In order to exit a multi-user chat room, an occupant sends a presence stanza of type \"unavailable\"

Answer 1

The Whatsapp model is much simpler than you imagine - they just maintain user session online even if user disconnects, and re-sends messages when he "reattach" session. XEP-0198 introduce similar concept to traditional XMPP sessions. You only need to configure longer inactivity period (typically XEP-0198 assume 300 seconds, but whatsapp-like messengers holds session 24+ hours)

Answer 2

XEP-45 was designed more then 10 years ago. Back then, the designers had something like IRC channels in mind. Everything of XEP-45 is designed based on the assumption that a user enters and leaves a room when he/she starts/terminates its client.

WhatsApp Groupchats are different: A user joins a groupchat is is able to view the (complete) history of that chat. Even if the users client is offline/unavailable, he is still considered part of the groupchat.

The XMPP community currently works on a new XEP that provides such functionality. It is called XEP-0369: Mediated Information eXchange. It is the spiritual successor of XEP-0045, providing the features one would expect from modern groupchats.

Answer 3

Yes you can make your group persistent by setting its configurations this way:

NSString *var = [field attributeStringValueForName:@"var"];
if ([var isEqualToString:@"muc#roomconfig_persistentroom"])
{
    [field removeChildAtIndex:0];
    [field addChild:[NSXMLElement elementWithName:@"value" stringValue:@"1"]];
}

Answer 4

You could emulate something quite like this by using server-side history of the MUC (Message Archive Management, XEP-0313), so that when a client logs in they're able to request the history of the MUC while they weren't in it.

If you also want to be able to show the offline pseudo-occupants of a room, the easiest way to do this is probably to map a pubsub node per room to store the list of these pseudo-occupants that clients could read to supplement the usual occupancy list.

There are probably other solutions here, but those that come immediately to mind for me involve changing the behaviour of the server in non-standard ways, such as allowing normal occupants to query a membership list, which normally only admins can do.