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.

Looking for expert support and management for your ejabberd deployment?
Contact ProcessOne today »

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.

Several workarounds had been tried by developers:

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.

The specification is called XEP-0369: Mediated Information eXchange (MIX). ejabberd already implements the draft since a few months and we are actively working on it and supported the effort.

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.
  • Rely on Message Archive Management to let client resync history as they need.
  • Rely on existing Push components (ProcessOne extension or XEP-0357: Push Notifications) to send events to mobile devices when application is asleep.

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 !

Let us know what you think 💬

28 thoughts on “XMPP Mobile groupchat — Introducing MUC Subscription

  1. Do you plan to publish MUC Sub as an XEP so other servers can implement it as well?

    • Of course, we would be glad to work with XSF to make the needed changes to reach the point where it could be a XEP. We are also open to changes suggested by clientsor server developers:)

    • 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.

  2. 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.

  3. 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.

    Thanks for helping me out.

  4. Hi,

    How do we get list of subscribers of a room? This equals to list of group member in Whatsapp.

    Which one do you suggest for modern group chat in XMPP: MUC with subscription or MIX?

    Thank you

  5. For me, the does not contain the notification from the MUC (like the one-to-one chat does) when it publishes the message to my push component. any advice?

    thank you

    • wordpress stripped my xml from my comment above.
      so, in the publish payload ejabberd sends to my push component i only have the notification tag, empty. it doesn’t contain the message sent to the room.
      any idea what’s going on?

  6. hi,
    how do we get the list of subscriptions – list of rooms the user is subscribed to? is there an http-api for it?

  7. Hi Mickaël,
    How can i keep roles like visitor or participant in persistence using muc-sub. As i need to allow admin of group chat to kick/ban any occupant or make him a visitor. Can we change the role of any offline member.

    • Hello,

      Roles are only used by online members, offline one use only affiliations.
      Roles are only keep for users when they are online as they do not always make sense in the offline case.
      For example how you kick someone who uses mucsub? in normal situations user could just join again, but how that could work with mucsub?

      So no, you cannot set roles for Mucsub users, but you can still ban a user.

  8. Thanks for you reply Mickaël. Ban instead of Kick is fine and that works pretty well.

    My only concern now is how do i revoke voice from some subscribers(make them visitor) and let some other subscribers have voice. One way i think is by having a moderated group with default member role as participant so they don’t have voice, and to grant voice i can make them admin. But that is not a pretty hack. Please suggest if there is anything else i can do or if there is any patch available for making role persistent.


Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.