Skip to content

MUC Light

Jump to bottom Edit New page
Brujo Benavides edited this page Nov 9, 2015 · 1 revision

Motivation

It has shown that the traditional approach on how to do group chat (MUC) does not fit the mobile use case where clients come and go quite frequently but don't want to stay connected for a long time. A presence based approach implies a lot of bandwidth and engineering overhead in this case as messages should be received independently of whether a client is truly connected or not. So presence would have to be faked somehow while at the same time presence updates from other entities might not be of importance that much.

Use cases (proposed protocol)

The proposed protocol is mostly a subset of XEP-0045 with minor deviations. Those are mentioned separately. Most notably we're not sending presence here.

Creating a room

No presences = we use IQ for creating instant rooms.

Setting a configuration for non-existing room equals creating a room.

Setting/getting configuration

Standard XEP-0045 method. Configuration options list should be strongly limited. Everyone is allowed to get room configuration (e.g. for getting current room title) but only owner can modify it (except for the subject, which can be changed by anyone). Configuration fields should not have any human-readable descriptions, labels etc., since config options will be application specific.

For getting the configuration:

<iq from='crone1@shakespeare.lit/desktop'
    id='config1'
    to='coven@chat.shakespeare.lit'
    type='get'>
  <query xmlns='http://jabber.org/protocol/muc#owner'/>
</iq>
<iq from='coven@chat.shakespeare.lit'
    id='config1'
    to='crone1@shakespeare.lit/desktop'
    type='result'>
  <query xmlns='http://jabber.org/protocol/muc#owner'>
    <x xmlns='jabber:x:data' type='form'>
      <field type='hidden' var='FORM_TYPE'>
        <value>http://jabber.org/protocol/muc#roomconfig</value>
      </field>
      <field var='roomname'>
        <value>A Dark Cave</value>
      </field>
    </x>
  </query>
</iq>

Setting configuration:

<iq from='crone1@shakespeare.lit/desktop'
    id='create2'
    to='coven@chat.shakespeare.lit'
    type='set'>
  <query xmlns='http://jabber.org/protocol/muc#owner'>
    <x xmlns='jabber:x:data' type='submit'>
      <field var='FORM_TYPE'>
        <value>http://jabber.org/protocol/muc#roomconfig</value>
      </field>
      <field var='roomname'>
        <value>A Dark Cave</value>
      </field>
    </x>
  </query>
</iq>
<iq from='coven@chat.shakespeare.lit'
    id='create2'
    to='crone1@shakespeare.lit/desktop'
    type='result'/>

Adding/removing members

Members will be added/removed with modifying their affiliation.

Member can be added by room owner or member (if room/service configuration allows it):

<iq from='crone1@shakespeare.lit/desktop'
    id='member1'
    to='coven@chat.shakespeare.lit'
    type='set'>
  <query xmlns='http://jabber.org/protocol/muc#admin'>
    <item affiliation='member' jid='hag66@shakespeare.lit'/>    
  </query>
</iq>
<iq from='coven@chat.shakespeare.lit'
    id='member1'
    to='crone1@shakespeare.lit/desktop'
    type='result'/>

Service will route a message to the members about affiliation change (optional and not necessarily handled by service itself, might just be client side thing to send these):

<message from='coven@chat.shakespeare.lit' to='member@shakespeare.lit' type='groupchat'>
  <x xmlns='mongooseim:muc:light'>
    <item affiliation='member' jid='hag66@shakespeare.lit'/>    
  </x>
  <body>User X has been added to the member list.</body>
</message>

Member can be removed by the owner by him/herself:

<iq from='crone1@shakespeare.lit/desktop'
    id='member2'
    to='coven@chat.shakespeare.lit'
    type='set'>
  <query xmlns='http://jabber.org/protocol/muc#admin'>
    <item affiliation='none' jid='hag66@shakespeare.lit'/>
  </query>
</iq>
<iq from='coven@chat.shakespeare.lit'
    id='member2'
    to='crone1@shakespeare.lit/desktop'
    type='result'/>

If the owner leaves, new owner is chosen randomly amongst remaining members. Owner can also specify new owner when leaving in single request:

<iq from='crone1@shakespeare.lit/desktop'
    id='member2'
    to='coven@chat.shakespeare.lit'
    type='set'>
  <query xmlns='http://jabber.org/protocol/muc#admin'>
    <item affiliation='none' jid='crone1@shakespeare.lit'/>
    <item affiliation='owner' jid='hag66@shakespeare.lit'/>
  </query>
</iq>

Service will route a message to the members about affiliation change (optional and not necessarily done by service):

<message from='coven@chat.shakespeare.lit' to='member@shakespeare.lit' type='groupchat'>
  <x xmlns='mongooseim:muc:light'>
    <item affiliation='none' jid='crone1@shakespeare.lit'/>
    <item affiliation='owner' jid='hag66@shakespeare.lit'/>
  </x>
</message>

Getting member list

Standard XEP-0045 way:

<iq from='crone1@shakespeare.lit/desktop'
    id='member3'
    to='coven@chat.shakespeare.lit'
    type='get'>
  <query xmlns='http://jabber.org/protocol/muc#admin'>
    <item affiliation='member'/>
    <item affiliation='owner'/>
  </query>
</iq>

Server responds with all users that are member or owner:

<iq from='coven@chat.shakespeare.lit'
    id='member3'
    to='crone1@shakespeare.lit/desktop'
    type='result'>
  <query xmlns='http://jabber.org/protocol/muc#admin'>
    <item affiliation='member' jid='hag66@shakespeare.lit'/>
  </query>
</iq>

Sending (and receiving) a message

<message
    from='hag66@shakespeare.lit/pda'
    id='hysf1v37'
    to='coven@chat.shakespeare.lit'
    type='groupchat'>
  <body>Harpier cries: 'tis time, 'tis time.</body>
</message>

Message is routed to all members:

<message
    from='coven@chat.shakespeare.lit/hag66@shakespeare.lit'
    id='E36F45B8-DE06-4534-94AD-C5ED29415FCE'
    to='crone1@shakespeare.lit/iphone'
    type='groupchat'>
  <body>Harpier cries: 'tis time, 'tis time.</body>
</message>

<message
    from='coven@chat.shakespeare.lit/hag66@shakespeare.lit'
    id='E36F45B8-DE06-4534-94AD-C5ED29415FCE'
    to='crone1@shakespeare.lit/tablet'
    type='groupchat'>
  <body>Harpier cries: 'tis time, 'tis time.</body>
</message>

<message
    from='coven@chat.shakespeare.lit/hag66@shakespeare.lit'
    id='E36F45B8-DE06-4534-94AD-C5ED29415FCE'
    to='crone2@shakespeare.lit/android
    type='groupchat'>
  <body>Harpier cries: 'tis time, 'tis time.</body>
</message>

Changing the room's subject

(That's just taken as is from XEP-0045 again) Room's subject automatically becomes the room name (injected into configuration).

Occupant changes subject:

 <message
    from='wiccarocks@shakespeare.lit/laptop'
    id='lh2bs617'
    to='coven@chat.shakespeare.lit'
    type='groupchat'>
  <subject>Fire Burn and Cauldron Bubble!</subject>
</message>

Service informs occupants about change of subject:

<message
    from='coven@chat.shakespeare.lit/wiccarocks@shakespeare.lit'
    id='5BCE07C5-0729-4353-A6A3-ED9818C9B498'
    to='crone1@shakespeare.lit/desktop'
    type='groupchat'>
  <subject>Fire Burn and Cauldron Bubble!</subject>
</message>

[ ... ]

Room destruction

Room is destroyed automatically when everyone leaves (ie, affiliations being set to ‘none’).

Add a custom footer
Add a custom sidebar
Clone this wiki locally