14

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" to the <room@service/nick> it is currently using in the room.

Example 80. Occupant Exits a Room

<presence
    from='hag66@shakespeare.lit/pda'
    to='coven@chat.shakespeare.lit/thirdwitch'
    type='unavailable'/>

This implies that as soon as the user disconnects from the XMPP server, he is removed from the group on the server side. The issue is simple — I don't want this behavior; I want a behavior that is similar to what Whatsapp does, i.e. even if the user goes offline, he is still part of the MUC room (which is configured to be persistent on the server side) and will receive messages from other occupants.

Given the spec and the documentation for XEP-0045 and XMPPFramework for iOS, I have no idea how to accomplish this or if it's possible to accomplish this in the traditional ejabberd server.

Flow
  • 23,572
  • 15
  • 99
  • 156
p0lAris
  • 4,750
  • 8
  • 45
  • 80
  • There is now also a newer XEP (0369) which fulfills your requirement: http://xmpp.org/extensions/xep-0369.html – JC Brand Jun 28 '16 at 13:59

4 Answers4

9

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.

Flow
  • 23,572
  • 15
  • 99
  • 156
5

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.

Kev
  • 2,234
  • 1
  • 12
  • 6
  • Thanks Kev. There are further issues with implementing custom solutions. Message archiving is good but what about notifications? The offline users will never be notified of any messages from the server unless they actually open the app. Further as I think more about this, can I simply just use PubSub as my model instead of the traditional MUC? – p0lAris Sep 22 '14 at 21:56
  • You could rebuild MUC on top of pubsub, yes, although that's a bunch of work. You could also keep the session alive and get notifications from the server. Unfortunately nothing's standardised yet, but there was a great deal of discussion of a mechanism for doing exactly this at the XMPP summit in February this year, and a spec is in the works. – Kev Sep 23 '14 at 06:55
  • Ok. So that's out of the window given we don't have too much time on our hands. But going with the actual suggestion — how does one keep the xmpp session alive indefinitely in iOS? I know people have answered similar to this but I am not sure I understand it right. – p0lAris Sep 23 '14 at 07:45
  • @Kev is the current state of the XEP available somewhere? What's its name? – Flow Sep 23 '14 at 10:45
5

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)

vitalyster
  • 4,980
  • 3
  • 19
  • 27
  • Thanks vitalyster. "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." Is this on the server side? If so, they are possibly overriding the 'unavailable' presence with 'available' presence. As far as the XEP-0198 is concerned, I am unsure how this could be implemented in the context of an iOS app. – p0lAris Sep 22 '14 at 23:45
  • for example, if you basically terminate the iOS app — your stream would get disconnected. – p0lAris Sep 22 '14 at 23:47
  • If you terminate iOS app - stream will be disconnected, but session remain active, they just ignore TCP disconnects, not presences. Because you still able to go offline from status menu and leave groupchat too. And with XEP-0198 you got the same. – vitalyster Sep 23 '14 at 06:43
  • 1
    I have just been scrambling the internet and have now read stream management XEP 0198 and I still don't clearly understand how Whatsapp does it or how its done according to you. If the stream is disconnect, how can I keep the session alive on iOS? Say for example — a simple network issue OR if the user manually terminates the app. Can you explain in terms of how I should enable this functionality on the client side in terms of simple pseudo code. That will really help a lot. – p0lAris Sep 23 '14 at 06:53
  • What is the problem to read XEP-0198 itself? http://xmpp.org/extensions/xep-0198.html - you only need to implement stanza acking (no need to do requests) and session resuming. BTW, you mentioned iOS and Objective-C, XMPPFramework already supports XEP-0198 – vitalyster Sep 23 '14 at 10:17
  • 1
    And for making session "alive" - it is done on *server* side, not on the client side. – vitalyster Sep 23 '14 at 10:20
  • There are still some issues. Even if you have resumed your stream you still have to query for incoming messages by sending the last message timestamp. I don't know if it is possible to query message without leaving and rejoining the group (or may be there is some iq). One thing xmpp muc would certainly benefit is persistent session like Pubsub. You reconnect automatically, neatly and receive all the messages. It is all server's responsibility and client is simple. – Harshit Bangar Dec 23 '15 at 05:48
1

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"]];
}
Fatima Arshad
  • 350
  • 2
  • 5