Ejabberd bookmarks vs subscribe in a typical group chat

Question

I am working on a group chat application using ejabberd.

Usecase:

What I want to develop is a whatsapp like group chat. User once joined the group chat they must be able to receive the message until they intentionally leave the chat.

What I tried :

I configured ejabberd (from docker image ejabberd/ecs) successfully and added few users to it. I am using mysql as database. MUC module is configured so that it uses mysql to store muc rooms and users data. I tried below steps to configure rooms and users.

1. Created user with ejabberctl
2. created room with persistent true configuration from ejabbberdctl.
3. User joined the room from xmpp client (tried different clients) with option to automatically rejoins the room.

Assumption and actual :

My assumption was the mysql table muc_room_subscribers would have an entry of the above user. But it is empty. The bookmark is added to the private_storage table and the xmpp client get this data (I assume) and rejoins the group chat once the user is reconnected. So of course my requirement meets, But I want to develop my own client. Wondering how the muc room subscription supposed to deal.

How it is supposed to do ? :

In order to develop a group chat application, do i need to add a bookmark for the joined room against the user in the background and if the user is disconnected use push notification to notify the user and if the user reconnect then rejoin to the muc room. Is this how it is supposed to implement?

Question about subscribe :

Then, What is the purpose of muc_subscribers? In what use case we can use this? The typical group chat (whatsapp like) doesn't need a subscription?

Answer 1

There are two different topics here, MUC and MUC/Sub. Let's describe slowly until we reach the confusion point.

What I want to develop is a whatsapp like group chat.

Ok, then probably XEP-0045 (called Multi-User Chat, or MUC) is the protocol you want.

Particularly in ejabberd:

• that protocol is implemented in mod_muc.erl and mod_muc_room.erl
• the server configuration is documented in mod_muc
• the user that creates a room can configure some aspects of that room using the XMPP client
• there are some API commands to administer the MUC service and MUC rooms
• the persistent tables used by those modules in Mnesia are muc_room (for persistent rooms), muc_registered (for nicks registered in the MUC service), and the temporary table muc_online_room (for details about online rooms, like occupants, recent messages). If using SQL, the table names vary slightly

User once joined the group chat

As defined in https://xmpp.org/extensions/xep-0045.html#enter

they must be able to receive the message

As defined in https://xmpp.org/extensions/xep-0045.html#message

until they intentionally leave the chat.

As defined in https://xmpp.org/extensions/xep-0045.html#exit

And now comes what confused you: there's a proposed protocol that uses only some parts of MUC, and replaces precense information with subscription information. That complementary protocol is defined in MucSub: Multi-User Chat Subscriptions

the mysql table muc_room_subscribers

Then, What is the purpose of muc_subscribers?

That table is used for implementing Muc/Sub

The bookmark is added to the private_storage table

That is XEP-0049: Private XML Storage which each XMPP client can use to store whatever it wants. Some clients store there MUC rooms to autojoin on login, or any other random data that the client may want to store for its features.. Notice that's used for features defined by each specific client, ejabberd only takes care to store the data.