Millions of private MUC rooms or dynamic XEP-0033 conversations in ejabberd: what is the best?

3
votes

Needs

I have the following scenario:

  • ~100 thousand players
  • 50 admins

Each player may have 1:1 conversations with each admin; a player may even have 1:1 conversations with all admins at the same time in separate conversations.

But at any time the admin of one of these conversations may invite another (or many) admin into one of these thousands of conversations.

Additional:

  • ALL messages stored with MAM with default:always
  • Stream Management with resend_on_timeout:true.
  • A player cannot message another player

Example:

  • Let's say player 1 has 3 active separate conversations P1:Admin A, P1:Admin G, P1:Admin H
  • Then admin A invites Admin H into the P1:Admin A conversation (the fact that Admin H was invited into Admin A's conversation won't close the active P1:Admin H conversation), player will then have these active conversations:
    • P1:Admin A + Admin H, P1:Admin G, P1:Admin H

Solution #1: Muc Rooms

I am thinking in making all conversations into private non-discoverable MUC rooms (when an user wants to chat with an admin, the client will issue a custom IQ that an ejabberd module that I'll develop will handle and create the room, putting the player and admin automatically whitelisted in this new room).

For the example scenario that could mean 5 million MUC rooms. I know 5 million normal chats is a common scenario, but is it ok to have this amount of rooms?

Solution #2: XEP-0033 Extended Stanza Addressing

For this solution I was thinking of having messages to be identified to be part of a room with an extended element channel. This way recipients may enter and go a conversation.

But this doesn't have the security control of MUC rooms, which only whitelisted users may talk in a channel. Is there a way to overcome this privacy thing with this approach?

An example using the channel element:

P1:Admin A + Admin B, room 1

<message to='header.org' from='player1'>
   <addresses xmlns='http://jabber.org/protocol/address'>
     <address type='to'  jid='adminA'/>
     <address type='to'  jid='adminB'/>
   </addresses>
   <channel xmlns='chanel:namespace' id='1'>
   <body>Hi admin A and admin B!</body>
</message>

Admin B lefts, P1:Admin A, still room 1

<message to='header.org' from='player1'>
   <addresses xmlns='http://jabber.org/protocol/address'>
     <address type='to'  jid='adminA'/>
   </addresses>
   <channel xmlns='chanel:namespace' id='1'>
   <body>Hi admin A only on the same room!</body>
</message>

Final solution?

Considering that client and server customisation is not a problem... Which solution is the best, considering all requirements? Or is there another optimal solution?

1
xmppejabberdmultiuserchat
This is crazy because I'm facing the SAME EXACTLY architecture problem. But in my case most of the time the conversations will be 1:1, but at anytime, any of them may need to add more persons (admins as in your example), I'm leaning toward "converting one to one chat into muc conference" – I'll structure my thoughts and post an answer here, so you may consider it. – AlfredBaudisch

1 Answers

2
votes

I have a similar setup and this is how I approached it: conversations start as 1:1 chat, since most of them will always be 1:1, but if an admin wants to invite another admin or even another user, I convert the chat into a MUC conference as described in XEP-0045.

These conference rooms are hidden and members only, but they aren't persistent (destroyed after the last occupant exits).

The multicast strategy (XEP-0033) is also Ok if you are going to use a custom client only. You won't have control of rooms if you are using existing clients.