%ents; ]>
Mediated Information eXchange (MIX) This document defines Mediated Information eXchange (MIX), an XMPP protocol extension for the exchange of information among multiple participants through a mediating service. The protocol can be used to model group communication applications such as chatrooms, although with greater flexibility and extensibility than existing groupchat technologies such as Multi-User Chat (MUC). Although MIX supports standard groupchat features such as discussion topics and invitations, and also defines a strong access control model similar to that of MUC, it enables users to participate without sharing presence, allows communication of any structured data (not only textual messages), reuses Publish-Subscribe so that users can receive only the information formats in which they are interested, and reuses Message Archive Management (MAM) to provide more robust storage and archiving. &LEGALNOTICE; 0369 Experimental Standards Track Standards Council XMPP Core XMPP IM XEP-0004 XEP-0030 XEP-0060 XEP-0313 MIX &ksmithisode; &stpeter; 0.1 2016-01-07 XEP Editor (asw)

Initial published version approved by the XMPP Council.

0.0.1 2015-10-12 kis/psa

First draft.

Multi-User Chat (MUC) is a major application of XMPP that was developed in 2002 and standardized in &xep0045;. 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:

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

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.

The following concepts underlie the design of MIX.

MIX is based upon domains providing a MIX service, such as `mix.shakespeare.example`. Note that although PubSub communication is used, a domain used for MIX is a MIX domain and not a standard &xep0060; domain. (Note that, like in MUC, there is no requirement on the naming of these domains; the label 'mix' and the fact that it is a subdomain of a 'shakespeare.example' service is purely an example).

Every MIX conversation is an addressable PubSub service (with additional MIX semantics) that will be addressed by an XMPP client using a bare JID, for example coven@mix.shakespeare.example. While &xep0060; is used as the basis for the MIX model, some protocol is added or optimised in this document for the MIX use cases. For example, when a message is published to the 'urn:xmpp:mix:nodes:messages' node, a message unlike a &xep0060; payload is distributed to occupants (more akin to the old &xep0045;); this enables standard XMPP semantics of message stanzas to be used.

Message Archive Management is used for all storage of historical data (such as the history of messages sent within the conversation). Each node can be archived separately (e.g., the presence node or the configuration node). MIX clients can retrieve information archived in MAM in order to quickly resync with regard to a conversation, and can do so without necessarily providing presence information.

The standard nodes are as follows (although note that not every conversation will necessarily use each node):

  • 'urn:xmpp:mix:nodes:messages' for publishing messages. Each item of this node will contain one message, containing each of the distributed payloads.
  • 'urn:xmpp:mix:nodes:subject' for publishing the subject of the conversation.
  • 'urn:xmpp:mix:nodes:participants' for publishing the list of participants, including their details (e.g., the participant JIDs in an appropriately configured conversation). This is equivalent to the "room roster" in MUC.
  • 'urn:xmpp:mix:nodes:presence' for publishing information about the availability status of the participants. This is a significant departure from MUC, where occupancy and presence were tightly coupled. In MIX it is possible to have a 'presenceless conversation' by not using this node. As another significant departure from MUC (where a participant is active in the room from multiple resources), information about the presence of each resource associated with an account is individually available, as is normal outside MUC.
  • 'urn:xmpp:mix:nodes:config' for storing configuration information. In another departure from MUC, by storing configuration in the same manner as other data, it is possible to tweak access rights such that participants are able to read the configuration if desired. A further benefit is that notifications of configuration changes fall out "for free".
  • 'urn:xmpp:mix:nodes:acl' for storing information about access control lists (such as the list of owners and moderators). Naturally this information might be restricted to authorized users.

To determine if a domain hosts a MIX service, a &xep0030; info query should be sent in the usual manner

]]>

The MIX service then MUST return its identity and the features it supports, which MUST include the 'urn:xmpp:mix:0' feature, and the identity MUST have a category of 'conference' and a type of 'text'. TODO: do we want a different type?

urn:xmpp:mix:0#serviceinfo chat.shakespeare.example ]]>

If the MIX service is mirrored to a MUC service for backwards-compatibility, this SHOULD be signaled by the inclusion of a 'urn:xmpp:mix:nodes:muc_mirror' field, the value of which is the mirrored MUC domain, in the extended disco results in a form whose type value is 'urn:xmpp:mix:0#serviceinfo'. Note that the MIX service itself doesn't advertise support for &xep0313;, nor is support for generic &xep0060; advertised.

There is no need for using Service Discovery here, since the MIX service provides a node "urn:xmpp:mix:nodes:conversations" that pushes out one event for each conversation that has been created at the service.

In order to find out more information about a given conversation, a user can send a disco#info query to the conversation.

]]>

The conversation MUST return its identity and the features it supports:

]]>

Use disco#items to find the nodes associated with a conversation.

]]> ]]>

*Not* done with disco#items (which returns nodes), instead query items on the "urn:xmpp:mix:nodes:participants" node (if you're allowed).

A user joins a conversation by sending a MIX "join" command. There's no default set of nodes: all nodes must be specified if the user wants that information (but clients should pick the standard MIX ones at least by default for normal usage). It's possible to forward-subscribe to nodes that don't yet exist, in case they're added (e.g., presence added to a MUC). The server injects a new item into the "urn:xmpp:mix:nodes:participants" node automatically. TODO: include the nickname at this point?

]]>

The conversation must process the join atomically. The conversation responds with an IQ-result. This stanza includes the nodes to which the user was subscribed, as well as the JID that will be used for the user in this room (real JID for non-anonymous rooms, proxy JID for semi-anonymous rooms). TODO: does this need to always be a proxyJID? List discussion.

]]>

As noted, the participant might not be subscribed to all nodes (in this case only messages, participants, and subject).

]]>

The conversation also adds the user to the participants node and sends a notification.

]]>

Each <participant> element includes a 'jid' attribute, which is the stable participant identifier for this user in this conversation. TODO: proxy/realJID mapping (admins might see real JIDs even in a semianon room)

A user can register with the MIX service (not any particular conversation) by sending a <register/> command to the service. TODO: This should be available either room or service-based, with discovery.

thirdwitch ]]>

On success, the service informs the user of its nick. The nick that is issued might be different from the nick that was requested, for example if the service completes normalization of nicknames for purposes of internationalization.

MIX services SHOULD apply the "nickname" profile of the PRECIS OpaqueString class, which is defined in draft-ietf-precis-nickname.

thirdwitch ]]>

If the requested nick is already taken, the MIX service returns a <conflict/> error:

thirdwitch ]]>

If the register request does not contain a <nick/> element, then the MIX service assigns one (this SHOULD be a UUID). TODO: Discuss - is there any reason for this to be a UUID? Surely anything the server wants to assign is fine (with security consideration about leaking JID information).

Participation in the conversation is decoupled from sending presence through the conversation. A participant comes online by publishing availability to the "urn:xmpp:mix:nodes:presence" node. TODO: Move back to using presence normally (suggested with rooms in rosters), for correct 'offline' behaviour, etc.

thirdwitch ]]>

The user's presence information is then published by the service to the "urn:xmpp:mix:nodes:presence" node, with the 'publisher' attribute set to the user's participant identifier. TODO: List discussion on the benefits of wrapping vs. normal presence.

thirdwitch ]]>

To go offline, the user sends a normal unavailable stanza (usually through their server's usual offline broadcast rules).

]]>

The conversation retracts the item and notifies subscribers to the presence node. TODO: Update depending on discussion about events vs. presence.

A user sends a message by publishing it to messages node. TODO: List discussion about type=groupchat messages vs. xep60 publish.

Harpier cries: 'tis time, 'tis time. ]]>

The message comes from the conversation as a pubsub notification, with the 'publisher' attribute set to the participant identifier of the sender.

Harpier cries: 'tis time, 'tis time. ]]>

In order to permanently leave a conversation, a user sends a MIX "leave" command.

]]>

Note that leaving the conversation is a permanent action for a user across all clients, not just a matter of telling the conversation that the user is not currently available (as in MUC), or for a single client. If the user leaves the conversation, the MIX service is responsible for unsubscribing the user from all nodes in the conversation, and also for telling participants that the user is offline.

User sends to conversation requesting invite, receives it, forwards it to contact. Solves issues with both directed and mediated invites. ### TODO: Dave had a point about contact preverification about users' invites. Discuss.

Users' JIDs are available from the "urn:xmpp:mix:nodes:participants" node if the conversation is transparent.

TODO: transparent vs. opaque conversations

TBD.

Discuss normalization of nicknames.

TBD.

Topics to cover:

None.

Register a namespace.

TBD.

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.