XEP-xxxx: Mediated Information eXchange (MIX)

1. Introduction¶

Multi-User Chat (MUC) is a major application of XMPP that was developed in 2002 and standardized in Multi-User Chat (XEP-0045) [1]. This Mediated Infromation eXchange (MIX) protocol defined here implements the same basic MUC patterns in a more flexible and extensible way in order to address requirements that have emerged since MUC was developed. MIX supports all of the core chatroom features that are familiar from MUC, such as discussion topics and invitations. Like MUC, it also defines a strong access control model, including the ability to kick and ban users, to name moderators and administrators, and to require membership in order to participate in conversations.

MUC exists and works, so why replace it? There are several reasons:

• A number of use cases for group communication have emerged since MUC was first published.
• Experience has shown that it is difficult to use MUC to build several kinds of communication applications (such as a multimedia conference focus) without undesirable hacks.
• It is impractical to address a number of the requirements listed in the next section with MUC or with extensions to MUC.
• In the years after MUC was designed, both Publish-Subscribe (XEP-0060) [2] and Message Archive Management (XEP-0313) [3] have been developed and it is desirable to reuse these building blocks (e.g., MAM can be used for message history) rather than use the less robust methods defined in XEP-0045.

Because it is anticipated that there will significant co-existence between MUC and MIX, this specification is designed so that:

• XMPP clients can implement MUC and this specification in a way that provides a coherent user experience.
• XMPP servers can implement this specification and also provide a MUC interface in order to support clients that only implement MUC.

If a server wishes to expose both MUC and MIX representations of chatrooms, it SHOULD do so by serving MUC and MIX on different domains. The MIX service SHOULD include a reference to the MUC mirror, so that clients understanding both protocols can choose to only show one copy of the service.

2. Requirements¶

• Participation in a conversation can persist beyond clients being offline.
• Multiple devices associated with the same account can share the same handle in the conversation, with well-defined rules and all resources individually addressable.
• Conversations are not required to support or reflect presence for participants.
• A client that rejoins a conversation can quickly resync with respect to messages.
• A participant can be an invisible observer.
• Configuration can be observed from outside the conversation (e.g. list of participants, ability to reading messages, etc.).
• MIX services should not allow JIDs to be harvested.
• Play nicely with Message Archive Management (MAM).
• A user can can know which conversations they participate in, globally across all MIX services.
• Provide extensibility regarding data formats that can be sent within a conversation (files, structured data, indications about media sources in multimedia conferences, etc.) as well as flexibility regarding which data formats a user wants to receive.
• (Desirable) Make it easier to distribute a conversation across services in the spirit of "federated MUC" Federated MUC for Constrained Environments (XEP-0289) [4].
• (Desirable) Make it easier to reduce duplicate traffic.

3. Concepts¶

The following concepts underlie the design of MIX.

• MIX conversations (roughly equivalent to MUC rooms) are hosted on a MIX domain, e.g. `mix.example.com`, which is discoverable through Service Discovery (XEP-0030) [5]. Each conversation on the service may then be discovered and queried.
• Re-using the model from Personal Eventing Protocol (XEP-0163) [6] (where every user JID (e.g., `user@example.com`) is its own pubsub service), in MIX each conversation (e.g., `conversation@mix.example.com`) is a pubsub service.
• A conversation's pubsub service can contains any number of nodes for different event types or data formats. As described below, this document defines several standard nodes; however, future specifications or proprietary services can define their own nodes for extensibility.
• Affiliations with the nodes are, by default, tied together as affiliations on the conversation itself rather than individual nodes, so that allowing or denying access to a conversation is a single affiliation change.
• Message Archive Management (XEP-0313) [3] (MAM) is used for all history access, with each node being individually addressable for MAM queries. This simplifies implementation compared to MUC (which had a specialized and rather limited history retrieval mechanism).
• A client can achieve a 'quick resync' of a node by requesting just those changes it has not yet received, using standard MAM protocol. This solves the old MUC issue of either receiving duplicate messages when rejoining a room or potentially missing messages.
• Because MAM is used for history, only those nodes that have a 'current value' need to store any items in them - e.g. 'urn:xmpp:mix:nodes:presence' and 'urn:xmpp:mix:nodes:subject' would store their current values (with older values being queryable through MAM), while 'urn:xmpp:mix:nodes:messages' would store no items.
• A user's participation in a conversation outlives their presence session. A user who is offline will not share presence within the conversation, but will still be listed as an participant. This too is a significant departure from MUC.
• MUC2 decouples addressing of occupants from their nicknames, such that nickname changes don't affect addressing, adding flexibility.
• Each occupant is addressible by a single JID - in non-anonymous rooms these are just the ocucpant's 'real' JID such that messages between users are only mediated by the MUC2 service in semi-anonymous rooms. These are full JIDs, allowing transparency when a user has multiple online resources participating in the MIX.

4. Discovery¶

<iq from='hag66@shakespeare.example/intibo24'
    id='lx09df27'
    to='mix.shakespeare.example'
    type='get'>
  <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>

<iq from='mix.shakespeare.example'
    id='lx09df27'
    to='hag66@shakespeare.example/intibo24'
    type='result'>
  <query xmlns='http://jabber.org/protocol/disco#info'>
    <identity
        category='conference'
        name='Shakespearean Chat Service'
        type='text'/>
    <feature var='urn:xmpp:mix:0'/>
    <x xmlns='jabber:x:data' type='result'>
      <field var='FORM_TYPE' type='hidden'>
        <value>urn:xmpp:mix:0#serviceinfo</value>
      </field>
      <field var='urn:xmpp:mix:nodes:muc_mirror'
             label='Location of MUC mirror service'>
        <value>chat.shakespeare.example</value>
      </field>
    </x>
  </query>
</iq>

<iq from='hag66@shakespeare.lit/pda'
    id='ik3vs715'
    to='coven@mix.shakespeare.lit'
    type='get'>
  <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>
    

<iq from='coven@mix.shakespeare.lit'
    id='ik3vs715'
    to='hag66@shakespeare.lit/pda'
    type='result'>
  <query xmlns='http://jabber.org/protocol/disco#info'>
    <identity
        category='conference'
        name='A Dark Cave'
        type='mix'/>
    <feature var='urn:xmpp:mix:0'/>
  </query>
</iq>
    

<iq from='hag66@shakespeare.lit/pda'
    id='kl2fax27'
    to='coven@mix.shakespeare.lit'
    type='get'>
  <query xmlns='http://jabber.org/protocol/disco#items'/>
</iq>
    

<iq from='coven@mix.shakespeare.lit'
    id='kl2fax27'
    to='hag66@shakespeare.lit/pda'
    type='result'>
  <query xmlns='http://jabber.org/protocol/disco#items'>
    <item jid='coven@mix.shakespeare.example'
          node='urn:xmpp:mix:nodes:presence'/>
    <item jid='coven@mix.shakespeare.example'
          node='urn:xmpp:mix:nodes:participants'/>
    <item jid='coven@mix.shakespeare.example'
          node='urn:xmpp:mix:nodes:messages'/>
    <item jid='coven@mix.shakespeare.example'
          node='urn:xmpp:mix:nodes:subject'/>
    <item jid='coven@mix.shakespeare.example'
          node='urn:xmpp:mix:nodes:config'/>
  </query>
</iq>
    

5. Use Cases¶

<iq type='set'
    from='hag66@shakespeare.example'
    to='coven@mix.shakespeare.example'
    id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'>
  <join xmlns='urn:xmpp:mix:0'>
    <subscribe node='urn:xmpp:mix:nodes:messages'/>
    <subscribe node='urn:xmpp:mix:nodes:presence'/>
    <subscribe node='urn:xmpp:mix:nodes:participants'/>
    <subscribe node='urn:xmpp:mix:nodes:subject'/>
    <subscribe node='urn:xmpp:mix:nodes:config'/>
  </pubsub>
</iq>

<iq type='result'
    from='coven@mix.shakespeare.example'
    to='hag66@shakespeare.example'
    id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'>
  <join xmlns='urn:xmpp:mix:0' jid='hag66@shakespeare.example'>
    <subscribe node='urn:xmpp:mix:nodes:messages'/>
    <subscribe node='urn:xmpp:mix:nodes:presence'/>
    <subscribe node='urn:xmpp:mix:nodes:participants'/>
    <subscribe node='urn:xmpp:mix:nodes:subject'/>
    <subscribe node='urn:xmpp:mix:nodes:config'/>
  </pubsub>
</iq>
      

<iq type='result'
    from='hag66@shakespeare.example'
    to='coven@mix.shakespeare.example'
    id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'>
  <join xmlns='urn:xmpp:mix:0' jid='hag66@shakespeare.example'>
    <subscribe node='urn:xmpp:mix:nodes:messages'/>
    <subscribe node='urn:xmpp:mix:nodes:participants'/>
    <subscribe node='urn:xmpp:mix:nodes:subject'/>
  </pubsub>
</iq>
      

<message from='coven@mix.shakespeare.example'
         to='hecate@shakespeare.example'
         id='5A9C7398-DB13-4BFA-A091-2D466C710AAF'>
  <event xmlns='http://jabber.org/protocol/pubsub#event'>
    <items node='urn:xmpp:mix:nodes:participants'>
      <item id='33EB6D2A-3473-4FFB-82DF-C4290FB761E4'>
        <participant xmlns='urn:xmpp:mix:0'
                     jid='hag66@shakespeare.example'
                     nick='thirdwitch'/>
      </item>
    </items>
  </event>
</message>
      

<iq type='set'
    from='hag66@shakespeare.example/pda'
    to='mix.shakespeare.example'
    id='7nve413p'>
  <register xmlns='urn:xmpp:mix:0'>
    <nick>thirdwitch</nick>
  </register>
</iq>
      

<iq type='result'
    to='mix.shakespeare.example'
    from='hag66@shakespeare.example/pda'
    id='7nve413p'>
  <register xmlns='urn:xmpp:mix:0'>
    <nick>thirdwitch</nick>
  </register>
</iq>
      

<iq type='error'
    to='mix.shakespeare.example'
    from='hag66@shakespeare.example/pda'
    id='7nve413p'>
  <register xmlns='urn:xmpp:mix:0'>
    <nick>thirdwitch</nick>
  </register>
  <error type='cancel'>
    <conflict xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</iq>
      

<iq type='set'
    from='hag66@shakespeare.example/pda'
    to='coven@mix.shakespeare.example'
    id='hysf1v37'>
  <pubsub xmlns='http://jabber.org/protocol/pubsub'>
    <publish node='urn:xmpp:mix:nodes:presence'>
      <item>
        <presence xmlns='jabber:client'>
          <nick xmlns='http://jabber.org/protocol/nick'>thirdwitch</nick>
          <c xmlns='http://jabber.org/protocol/caps'
             hash='sha-1'
             node='http://code.google.com/p/exodus'
             ver='QgayPKawpkPSDYmwT/WM94uAlu0='/>
        </presence>
      </item>
    </publish>
  </pubsub>
</iq>
      

<message from='mix.shakespeare.example'
         to='hecate@shakespeare.example'
         id='77E07BB0-55CF-4BD4-890E-3F7C0E686BBD'>
  <event xmlns='http://jabber.org/protocol/pubsub#event'>
    <items node='urn:xmpp:mix:nodes:presence'>
      <item id='ae890ac52d0df67ed7cfdf51b644e901'
            publisher='3608A5E0C4C8'>
        <presence xmlns='jabber:client'>
          <nick xmlns='http://jabber.org/protocol/nick'>thirdwitch</nick>
          <c xmlns='http://jabber.org/protocol/caps'
             hash='sha-1'
             node='http://code.google.com/p/exodus'
             ver='QgayPKawpkPSDYmwT/WM94uAlu0='/>
        </presence>
      </item>
    </items>
  </event>
</message>
      

<presence type='unavailable'
    from='hag66@shakespeare.example/pda'
    to='coven@mix.shakespeare.example'/>
      

<iq type='set'
    from='hag66@shakespeare.example/pda'
    to='coven@mix.shakespeare.example'
    id='92vax143g'>
  <pubsub xmlns='http://jabber.org/protocol/pubsub'>
    <publish node='urn:xmpp:mix:nodes:messages'>
      <item>
        <body xmlns='jabber:client'>Harpier cries: 'tis time, 'tis time.</body>
      </item>
    </publish>
  </pubsub>
</iq>
      

<message from='mix.shakespeare.example'
         to='hecate@shakespeare.example'
         id='77E07BB0-55CF-4BD4-890E-3F7C0E686BBD'>
  <event xmlns='http://jabber.org/protocol/pubsub#event'>
    <items node='urn:xmpp:mix:nodes:messages'>
      <item id='bnd81g37d61f49fgn581'
            publisher='3608A5E0C4C8'>
        <body xmlns='jabber:client'>Harpier cries: 'tis time, 'tis time.</body>
      </item>
    </items>
  </event>
</message>
      

<iq type='set'
    from='hag66@shakespeare.example'
    to='coven@mix.shakespeare.example'
    id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'>
  <leave xmlns='urn:xmpp:mix:0'/>
</iq>
      

6. Configuration options¶

7. Internationalization Considerations¶

TBD.

Discuss normalization of nicknames.

8. Security Considerations¶

TBD.

Topics to cover:

• transparent vs. opaque conversations
• nickname registration and security implications of normalization

9. IANA Considerations¶

None.

10. XMPP Registrar Considerations¶

Register a namespace.

11. XML Schema¶

TBD.

12. Acknowledgements¶

Thanks to the participants in XMPP Summit 18 for their significant input during design sessions: Dave Cridland, Philipp Hancke, Waqas Hussain, Lance Stout, Sam Whited, and Matthew Wild.

Appendices

Appendix A: Document Information¶

Series

XEP

Number

xxxx

Publisher

XMPP Standards Foundation

Status

ProtoXEP

Type

Standards Track

Version

0.0.1

Last Updated

2015-10-12

Approving Body

XMPP Council

Dependencies

XMPP Core, XMPP IM, XEP-0004, XEP-0030, XEP-0060, XEP-0313

Supersedes

None

Superseded By

None

Short Name

MIX

This document in other formats: XML  PDF

Appendix B: Author Information¶

Kevin Smith

Email

kevin.smith@isode.com

JabberID

kevin.smith@isode.com

Peter Saint-Andre

Email

stpeter@stpeter.im

JabberID

stpeter@jabber.org

URI

https://stpeter.im/

Appendix C: Legal Notices¶

Appendix D: Relation to XMPP¶

The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 6120) and XMPP IM (RFC 6121) specifications contributed by the XMPP Standards Foundation to the Internet Standards Process, which is managed by the Internet Engineering Task Force in accordance with RFC 2026. Any protocol defined in this document has been developed outside the Internet Standards Process and is to be understood as an extension to XMPP rather than as an evolution, development, or modification of XMPP itself.

Appendix E: Discussion Venue¶

The primary venue for discussion of XMPP Extension Protocols is the <standards@xmpp.org> discussion list.

Discussion on other xmpp.org discussion lists might also be appropriate; see <https://xmpp.org/community/> for a complete list.

Errata can be sent to <editor@xmpp.org>.

Appendix F: Requirements Conformance¶

The following requirements keywords as used in this document are to be interpreted as described in RFC 2119: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", "OPTIONAL".

Appendix G: Notes¶

Appendix H: Revision History¶

Note: Older versions of this specification might be available at https://xmpp.org/extensions/attic/

1. Version 0.0.1 (2015-10-12)¶

   First draft.

   kis/psa

Appendix I: Bib(La)TeX Entry

@report{smith2015mix,
  title = {Mediated Information eXchange (MIX)},
  author = {Smith, Kevin and Saint-Andre, Peter},
  type = {XEP},
  number = {xxxx},
  version = {0.0.1},
  institution = {XMPP Standards Foundation},
  url = {https://xmpp.org/extensions/xep-xxxx.html},
  date = {2015-10-12/2015-10-12},
}

END