-
Notifications
You must be signed in to change notification settings - Fork 428
MUC Light
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.
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.
No presences = we use IQ for creating instant rooms.
Setting a configuration for non-existing room equals creating a room.
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.
<iq from='[email protected]/desktop'
id='config1'
to='[email protected]'
type='get'>
<query xmlns='http://jabber.org/protocol/muc#owner'/>
</iq><iq from='[email protected]'
id='config1'
to='[email protected]/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><iq from='[email protected]/desktop'
id='create2'
to='[email protected]'
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='[email protected]'
id='create2'
to='[email protected]/desktop'
type='result'/>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='[email protected]/desktop'
id='member1'
to='[email protected]'
type='set'>
<query xmlns='http://jabber.org/protocol/muc#admin'>
<item affiliation='member' jid='[email protected]'/>
</query>
</iq><iq from='[email protected]'
id='member1'
to='[email protected]/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='[email protected]' to='[email protected]' type='groupchat'>
<x xmlns='mongooseim:muc:light'>
<item affiliation='member' jid='[email protected]'/>
</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='[email protected]/desktop'
id='member2'
to='[email protected]'
type='set'>
<query xmlns='http://jabber.org/protocol/muc#admin'>
<item affiliation='none' jid='[email protected]'/>
</query>
</iq><iq from='[email protected]'
id='member2'
to='[email protected]/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='[email protected]/desktop'
id='member2'
to='[email protected]'
type='set'>
<query xmlns='http://jabber.org/protocol/muc#admin'>
<item affiliation='none' jid='[email protected]'/>
<item affiliation='owner' jid='[email protected]'/>
</query>
</iq>Service will route a message to the members about affiliation change (optional and not necessarily done by service):
<message from='[email protected]' to='[email protected]' type='groupchat'>
<x xmlns='mongooseim:muc:light'>
<item affiliation='none' jid='[email protected]'/>
<item affiliation='owner' jid='[email protected]'/>
</x>
</message>Standard XEP-0045 way:
<iq from='[email protected]/desktop'
id='member3'
to='[email protected]'
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='[email protected]'
id='member3'
to='[email protected]/desktop'
type='result'>
<query xmlns='http://jabber.org/protocol/muc#admin'>
<item affiliation='member' jid='[email protected]'/>
</query>
</iq><message
from='[email protected]/pda'
id='hysf1v37'
to='[email protected]'
type='groupchat'>
<body>Harpier cries: 'tis time, 'tis time.</body>
</message>Message is routed to all members:
<message
from='[email protected]/[email protected]'
id='E36F45B8-DE06-4534-94AD-C5ED29415FCE'
to='[email protected]/iphone'
type='groupchat'>
<body>Harpier cries: 'tis time, 'tis time.</body>
</message>
<message
from='[email protected]/[email protected]'
id='E36F45B8-DE06-4534-94AD-C5ED29415FCE'
to='[email protected]/tablet'
type='groupchat'>
<body>Harpier cries: 'tis time, 'tis time.</body>
</message>
<message
from='[email protected]/[email protected]'
id='E36F45B8-DE06-4534-94AD-C5ED29415FCE'
to='[email protected]/android
type='groupchat'>
<body>Harpier cries: 'tis time, 'tis time.</body>
</message>(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='[email protected]/laptop'
id='lh2bs617'
to='[email protected]'
type='groupchat'>
<subject>Fire Burn and Cauldron Bubble!</subject>
</message>Service informs occupants about change of subject:
<message
from='[email protected]/[email protected]'
id='5BCE07C5-0729-4353-A6A3-ED9818C9B498'
to='[email protected]/desktop'
type='groupchat'>
<subject>Fire Burn and Cauldron Bubble!</subject>
</message>
[ ... ]Room is destroyed automatically when everyone leaves (ie, affiliations being set to ‘none’).