The Mediated Information eXchange (MIX) protocol framework and core capabilities are specified in Mediated Information eXchange (MIX) (XEP-0369)  (MIX-CORE). This specification provides mechanisms to hide participant JIDs from other participants. This is needed to address privacy concerns and to prevent JID harvesting. It also addresses privacy issues, and gives participants options to control sharing of information.
Mediated Information eXchange (MIX) (XEP-0369)  exposes participant JIDs to other participants, and so messages MAY be sent directly. When JIDs are hidden this is no longer possible. Private messages MAY be sent to channel participants if allowed by channel policy. Private messages are switched through the channel to hide addressing. Private messages MAY be switched through the channel when JIDs are visible. This might be useful. for example where sending messages directly is blocked.
MIX channels have three modes controlling JID visibility, defined to prevent JID harvesting:
|'JID Visible'||In these channels all participant JIDs are visible to all channel participants.|
|'JID Maybe Visible'||In these channels, participant JIDs are visible to all channel participants when participant preference allows.|
|'JID Hidden'||In these channels, no participant JIDs are visible to channel participants, but they are visible to channel administrators.|
A channel participant MAY specify a preference for JID visibility for the channel, with one of the following values:
|'Prefer Visible'||The users JID will be visible if the channel is JID Visible or JID Maybe Visible channels and hidden if the channel is JID Hidden.|
|'Prefer Hidden'||The user's JID will be hidden if the channel is JID Maybe Visible and shown if the channel is JID Visible .|
|'Enforce Hidden'||The user's JID will never be shown and the user will be removed from channel if channel mode is changed to JID Visible.|
|'Enforce Visible'||The users JID will always be shown and the user will be removed from channel if mode is changed to 'JID Hidden'.|
The default value is 'Prefer Hidden'.
MUC hides real JIDs by using Nicks to identify room occupants. This has problems with Nick changing and with multiple active clients for the same user. MIX identifies channel participants by Stable Participant ID. In Mediated Information eXchange (MIX) (XEP-0369) , the user's JID is in the participants node and is shared in messages and presence. To hide JIDs, this specification makes three key changes
It is important that MUC owners and administrators are able to see the JIDs of participants. For this reason, a MIX channel following this specification MUST hold a JID Map node, which gives a mapping between Stable Participant ID and JID.
When JIDs are being hidden, the resource of the full JIDs stored in the presence node MUST also be anonymized using a similar mechanism. Where the JID is hidden, the resource is replaced with a generated value. For example, 'email@example.com/UUID-a1j/7533' in the channel coven might have an encoded JID of 'firstname.lastname@example.org/789'. There is no client visible mapping maintained, as this is not needed. The MIX channel will need to maintain a mapping, to support directly addressing clients, such as for client to client disco#info queries. While an encoded JID is held in the presence node, the mapping to real JID MUST NOT be changed. When adding a client to the presence node, the server MAY add the same anonymized JID as used before by that client, or it MAY create a different anonymized JID.
This specification defines a JID Map node, so that administrators can see JIDs for JID Hidden channels. This node MUST be present for JID Hidden and JID Maybe Visible channels. This node MAY be present for JID Visible channels. If this node is not present, JIDs will all be available in the participants node.
|JID Map||'urn:xmpp:mix:nodes:jidmap'||For storing a list of Stable Participant IDs from the participants node with a 1:1 mapping to the corresponding JIDs.||Automatic||PubSub|
The JID Map node is used to associate a Stable Participant ID to its corresponding bare JID. It is a PubSub node with the 'node' attribute set to 'urn:xmpp:mix:nodes:jidmap'. The JID Map node MUST have one entry for each entry in the Participants node. This value is added when a user joins the channel and is removed when the user leaves the channel. Each item is identified by Stable Participant ID mapping to the bare JID. This node is used to give administrator access to JIDs. A MIX server MUST NOT allow this node to be modified directly using pubsub. Only administrators can subscribe to this node. The JID Map node is a permanent node with one item per participant. Information is stored in a <participant/> element qualified by the 'urn:xmpp:mix:anon:0' namespace. The real JID is stored in a <jid/> child element of the <participant/> element.
A channel MAY store user preferences and parameters with each user. A user JID visibility preference has the following values:
The user MAY specify that no Private Messages are to be sent from the channel, and allow vCard retrieval.
The user MAY specify that presence is not to be shared, which will prevent the MIX Channel from sending a presence probe for the user on channel start-up. The user will also choose to not include the MIX channel in the user's roster, so that presence will not be updated. Where the channel configuration sets 'Participants Must Provide Presence', this variable MUST be set to 'Share'.
The following table sets out the standardized user preference values. A MIX implementation MAY use other values.
|'JID Visibility'||'default', 'never', 'always', 'prefer not'||'default'|
|'Private Messages'||'allow', 'block'||'allow'|
|'Presence'||'share', 'not share'||'share'|
When joining a channel, the client MAY specify one or more preference options as a Data Forms (XEP-0004)  form. In the response, the server MUST specify all of the user preferences supported by the server, with default values if the user has not requested a different value. The following example shows joining a channel and setting a preference. The following example shows the message sent from the user's server to the MIX channel, which will have been preceded by a message from the user's client to the user's server.
The following example shows the result of a successful join, which also reports all the user preferences. This example shows the message coming from the MIX channel to the user's server, which will be sent on to the user.
The client MAY also query the channel in order to find out which user preferences are supported and the options available. This will allow users to set options not specified in the standard, by providing a form template in the result. The request is encoded as a <user-preference/> child element of <iq/>. <user-preference/> is qualified by the 'urn:xmpp:mix:anon:0' namespace. The result is encoded as a form child element in the <user-preference/> element.
A user MAY modify preferences using the corresponding set operation. The set MAY specify values for some or all attributes. All attributes are returned in the result.
Private Messages are used to provide communication with another channel participant through the MIX channel. This may be used where the initiating user does not know the real JID of the channel participant or for other reasons. A message sent through the channel is addressed using the encoded JID of the client to which the message is being sent. Private messages will generally be sent to a bare JID, and this is shown in the following example. Private messages MAY be sent to a full JID.
The MIX channel will then process the message, to send to the real JID of the recipient. An encoded JID is used to identify the message sender.
Private Messages MUST NOT be archived by the MIX channel. Private Messages MAY be archived using MAM by the XMPP servers associated with initiator and responder.
See considerations in Mediated Information eXchange (MIX) (XEP-0369) .
See considerations in Mediated Information eXchange (MIX) (XEP-0369) .
The urn:xmpp:mix namespace needs to be registered.
To be supplied when MIX progresses to proposed standard.
See Mediated Information eXchange (MIX) (XEP-0369)  for a list of contributors to the MIX Family of specifications.
This document in other formats: XML PDF
This XMPP Extension Protocol is copyright © 1999 – 2020 by the XMPP Standards Foundation (XSF).
Permission is hereby granted, free of charge, to any person obtaining a copy of this specification (the "Specification"), to make use of the Specification without restriction, including without limitation the rights to implement the Specification in a software program, deploy the Specification in a network service, and copy, modify, merge, publish, translate, distribute, sublicense, or sell copies of the Specification, and to permit persons to whom the Specification is furnished to do so, subject to the condition that the foregoing copyright notice and this permission notice shall be included in all copies or substantial portions of the Specification. Unless separate permission is granted, modified works that are redistributed shall not contain misleading information regarding the authors, title, number, or publisher of the Specification, and shall not claim endorsement of the modified works by the authors, any organization or project to which the authors belong, or the XMPP Standards Foundation.
## NOTE WELL: This Specification is provided on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. ##
In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall the XMPP Standards Foundation or any author of this Specification be liable for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising from, out of, or in connection with the Specification or the implementation, deployment, or other use of the Specification (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if the XMPP Standards Foundation or such author has been advised of the possibility of such damages.
This XMPP Extension Protocol has been contributed in full conformance with the XSF's Intellectual Property Rights Policy (a copy of which can be found at <https://xmpp.org/about/xsf/ipr-policy> or obtained by writing to XMPP Standards Foundation, P.O. Box 787, Parker, CO 80134 USA).
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.
The primary venue for discussion of XMPP Extension Protocols is the <email@example.com> discussion list.
Discussion on other xmpp.org discussion lists might also be appropriate; see <http://xmpp.org/about/discuss.shtml> for a complete list.
Errata can be sent to <firstname.lastname@example.org>.
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".
Note: Older versions of this specification might be available at http://xmpp.org/extensions/attic/
Clarify how PMs can be used in JID Visible channels;
Remove vCard (now in MIX-PRESENCE); Update PM rules; Reflect changes in MIX-CORE and MIX-PRESENCE; New JID map format;
Split out from MIX 0.10.0;