XMPP Mobile groupchat — Introducing MUC Subscription

We are announcing today MUC Subscription, a new experimental feature in ejabberd that make group conversations in XMPP work seamlessly with mobile clients.

Toward persistent group chat participation

Today, a large proportion of XMPP chat projects are targeting both mobile, focusing on Whatsapp-like group conversations. Developers of such projects had been deeply frustrated because it was not possible to easily implement this feature on top of XMPP group chat features.

The main issue with XMPP group chat is that it is bound to user presence. Group chat in XMPP is based on XEP-0045: Multi-User Chat. It was designed to replicate IRC-like chat room, at a time where mobile internet connections were very rare. As a result, the protocol is based on presence. You join a room when you want to participate. You leave it when you are done.

On mobile, presence is almost irrelevant. You are always somewhat loosely reachable. However, your application may not run all the time because, to save battery life, mobile operating systems will hibernate your application when you are not actively using it. Mobile applications are supposed to be reachable through push notification services as they have generally no open TCP connection to the server in background state.

From XMPP point of view, it means that when the application is asleep, the XMPP client is not online. When it is not online, the user cannot be a participant in any chat room. He does not get messages nor notifications and thus misses events in the chat room.

Moreover, every time the user gets online, he has to rejoin all his ongoing conversations (MUC rooms). This is very consuming in terms of battery life and bandwidth.

However, none of this approach did prove to be an easy straightforward solution to the problem. It did not work very well in the sense that these work-around are not totally transparent and affect several parts of your client development.

MIX to the rescue

There is a work-in-progress at the XMPP Standard Foundation (XSF) that aims to build a full rework of the Multi-User Chat specification, taking the requirement to avoid relying on presence into account.

However, this is a work-in-progress that will take time before being fully usable as a Multi-User Chat replacement.

As we wanted to solve the problem today, for all XMPP developers, we decided to explore a path in-between. We developed a smaller, less ambitious extension, that solves the issues developers are facing to implement mobile group chat today. We are still committed to MIX implementation and we think our proposed extension will please mobile developers and help us channel feedback to the XSF to build future proof MIX specification.

Introducing MUC Sub

So, what is MUC Sub about and how is it designed ?

The goal of MUC Sub is to try to rely as much as possible on existing MUC specification, while making the smallest possible change that make mobile group conversation client easy.

We found that we only missed a few components. To play well with mobile, we just need to add the ability to send and receive messages to a room without having to send presence to the room. More generally we have to allow other type of interactions with the room (like configuration changes for example or kick and ban) without having to send presence to it to become a participant.

Basically, you need to be able to have a permanent subscription to a given room to receive the events. That subscription should grant you the right to send message and interact with the room. The name of our extension come from that simple idea: Add subscription feature to Multi-User Chat, hence MUC Sub.

We found we can put all the pieces together by reusing existing XMPP protocol components:

Reuse XMPP PubSub protocol to manage the subscription and wrap the events received as a subscriber from the room.

After writing a draft specification and a working implementation, we are very happy with the result: We have a working MUC Sub implementation that enables mobile group conversations. And we did all this by leveraging existing MUC specification and staying compliant with it.

The draft protocol is published on ejabberd documentation site: MUC Sub Draft

ejabberd main repository contains the code for MUC Sub. You can find it on Github: ejabberd.

The feature is enabled by default. To use it, just make sure you set the new parameter “Allow subscription” in the room on which you want to use it.

Next steps

We suggest, you can read the draft document we wrote, use the implementation and develop a mobile client.

Please, while you do so, send us your feedback about your success and troubles implementing your mobile group conversations.

MUC Sub is already available in ejabberd Community Edition repository and is going to be available as an experimental feature in ejabberd 16.07.

It will also be deployed as an experimental feature for ejabberd SaaS platform during the Summer. We are planning to test it as soon as possible with existing customers that are already willing to use it in production.

We hope you will like the approach and develop great new mobile clients thanks to ejabberd and MUC Sub !

Comment is not accurate. The issue with keeping long running sessions is that it is not permanent. It does not work well with server operations (restart, crashes). Moreover, we tried to modify the MUC to send offline messages to member for example, we went away from that approach because it is not as clean as having a true subscriber state. This also mean you can get configuration changes for exemple, etc.

Thanks for new feature, MUC with offline messages will be killer feature for ejabberd! But seems that it must be implemented on jabber clients for normal working? Or some clients already can work with this?

ejabberd MUC already supports offline: it is called Message Archive Management for MUC and allows users to download new messages and resync history. Nothing more is needed on the server and you can already implement it on client.

Yes, I can require archive for read old messages, but I don’t receive anything after restore online status.
For example, I am user1, I go online and create MUC chat, invite user2, send and receive some messages with him. After this I go offline, user2 send messages to this chat when I is offline. I return online status and don’t receive anything, no offline messages. So I must remember to join old MUC chat and load message archive for understand, was there new messages when I been offline.

I want to receive all “lost” offline messages from all MUC chats when I return to online, via normal popup messages like when I have online status.

This is a bad idea. If you are in several MUC, and are offline for a few days, you may easily received thousands of messages when you connect back, without control of it. It would “lock” your connections for minutes or even tens of minutes on slow mobile network.

What we do in MUC Sub is better. We provide a way to send push notifications and thus the app can store the ID of the room that will need refresh and can do so at an appropriate moment.

But Telegram, WhatsApp (that uses XMPP based protocol), Viber, Facebook and other modern messengers do this – I can easily create group chat with several users and each user always receive all messages from chat, even when I goes offline, as incoming (unread) message.

For not receive thousands of messages we can use limit (like now on ejabbed for offline messages) or ttl for 24 hours, for examplle.

What I am saying is that you can implement group chat with new message resync in XMPP. It is just that offline message for groupchat is not the right way to implement it. The software you are referring to use an approach close to what I describe, not generalized used of offline message in groupchat.

And if you limit offline message number, then you need to resync as iI describe, because otherwise you would not see some messages, so if you have to do that in the first place, then you are better off, taking full control of the message management on the client side.

The side benefit is that you can even chose the order in which you download message in conversation, most important first.

I have already install ejabberd 16.06. I check the “mod_muc.erl” there is no config for “allow_subscription”. How can i add allow_subscription in my existing ejabberd 16.06? I had tried to copy the mod_muc file from the git repo. But while compiling its throw error in rebar_abort, while further research i found the the error is due to xmpp.hrl not found in “include” folder. So can you help be out from this situation so that i am able to send the message without setting presence in MUC.