ejabberd MUC and MUC/Sub - Clarification

Question

I've recently been playing with the new MUC-Sub module in ejabberd - the use case being I need to have WhatsApp-like permanent rooms in my mobile app. Before I go too further into using MUC/Sub, can an ejabberd expert opine on the below concepts please? Is probably a lack of full knowledge of ejabberd on my part, hence the basic questions. Or else do let me know please a good place to start understanding the below better... I did study these two links in detail already (https://blog.process-one.net/xmpp-mobile-groupchat-introducing-muc-subscription/ and https://docs.ejabberd.im/developer/proposed-extensions/muc-sub/). Thanks!

Essentially, if we need an MUC room to stop being destroyed when all users go offline, could we not simply disable that feature - so that the service continues to operate even when participants leave or the room is empty. The service could still be made to continue pointing to the original room participants who joined the room, and in case there is a message sent in the room, the message would get queue up on each participant's stream. If a participant is offline, the message would enter his / her offline messages list (instead of the archive / MAM that MUC-Sub is currently utilizing). Why did we need to rely on the Pub-Sub and MAM model if this problem could have been solved using simply retention of the participant's reference in the room (even after he / she goes offline) and then leveraging the mod_offline module (which should happen automatically).

Am sure there is a fundamental reason here that am overlooking but appreciate if someone can throw some light please!

Answer 1

As the blog post explains, this is not a matter about keeping chat room alive or not. The fact that users cannot receive pushes when offline or when they reconnect, if they do not join again, is because MUC is based on presence. A user that is not present in the room is not an occupant of the room and is not supposed to receive anything.

I recommend you read careful XEP-0045 MUC and MUC Sub blog post again. The issue MUC Sub solves should be more obvious.

If you do that, you will notice that XEP-0045 define the idea of persistent MUC:

Persistent Room A room that is not destroyed if the last occupant exits; antonym: Temporary Room.

Default in ejabberd is to create the room as temporary when a user joins, but the setting of the room can be changed so that it becomes persistent. In that case, it is not destroyed when the last occupant leave. You need to change room configurations option (same form you used to enable MUC Sub on that room).

You would generally want to combine this option for the room with MUC Sub enabling, so that MUC room are kept around even if no user are present in it.