title: ejabberd MUC and MUC/Sub - Clarification
body: <p>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 (<a href="https://blog.process-one.net/xmpp-mobile-groupchat-introducing-muc-subscription/" rel="nofollow">https://blog.process-one.net/xmpp-mobile-groupchat-introducing-muc-subscription/</a> and <a href="https://docs.ejabberd.im/developer/proposed-extensions/muc-sub/" rel="nofollow">https://docs.ejabberd.im/developer/proposed-extensions/muc-sub/</a>). Thanks!</p>
  
  <p>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).</p>
  
  <p>Am sure there is a fundamental reason here that am overlooking but appreciate if someone can throw some light please!</p>