Welcome to Tigase Mediated Information eXchange (MIX) component guide. The MIX component allows you to have multi user group chats (channels), which are better suited for multi device usage.
Additionally, it provides basic support for MUC protocol to provide support and interoperability with older software not supporting MIX,
It is configured by default to run under the name
mix. Installations of Tigase XMPP Server (>= 8.2.0) run this component enabled by default under the same name even if not explicitly enabled/configured.
1.1. What is MIX?
MIX stands for Mediated Information eXchange (MIX) and it’s basics are defined in XEP-0369: Mediated Information eXchange (MIX):
“an XMPP protocol extension for the exchange of information among multiple users through a mediating service. The protocol can be used to provide human group communication and communication between non-human entities using channels, although with greater flexibility and extensibility than existing groupchat technologies such as Multi-User Chat (MUC). MIX uses Publish-Subscribe to provide flexible access and publication, and uses Message Archive Management (MAM) to provide storage and archiving.”
Specification outlines several requirements of which those seems to be the most interesting:
“A user’s participation in a channel persists and is not modified by the user’s client going online and offline.”
“Multiple devices associated with the same account can share the same nick in the channel, with well-defined rules making each client individually addressable.”
“A reconnecting client can quickly resync with respect to messages and presence.”
MIX itself serves as an umbrella for set of MIX-related XMPP extensions that specify the exact protocol. Two of them are required for the implementation to be considered as MIX compliant:
MIX-CORE defined in XEP-0369: Mediated Information eXchange (MIX) - “sets out requirements addressed by MIX and general MIX concepts and framework. It defines joining channels and associated participant management. It defines discovery and sharing of MIX channels and information about them. It defines use of MIX to share messages with channel participants.”
MIX-PAM defined in XEP-0405: Mediated Information eXchange (MIX): Participant Server Requirements - “defines how a server supporting MIX clients behaves, to support servers implementing MIX-CORE and MIX-PRESENCE.”
In addition to the above extensions, there are several other that are optional:
MIX-PRESENCE defined in XEP-0403: Mediated Information eXchange (MIX): Presence Support - adds the ability for MIX online clients to share presence, so that this can be seen by other MIX clients. It also specifies relay of IQ stanzas through a channel. (Not supported fully)
MIX-ADMIN defined in XEP-0406: Mediated Information eXchange (MIX): MIX Administration - specifies MIX configuration and administration of MIX.
MIX-ANON defined in XEP-0404: Mediated Information eXchange (MIX): JID Hidden Channels - specifies a mechanism to hide real JIDs from MIX clients and related privacy controls. It also specifies private messages. (Not supported fully)
MIX-MISC defined in XEP-0407: Mediated Information eXchange (MIX): Miscellaneous Capabilities - specifies a number of small MIX capabilities which are useful but do not need to be a part of MIX-CORE: handling avatars, registration of nickname, retracting of a message, sharing information about channel and inviting people, converting simple chat to a channel. (Not supported fully)
MIX-MUC defined in XEP-0408: Mediated Information eXchange (MIX): Co-existence with MUC - defines how MIX and MUC can be used tog
1.2. How does it work?
The most stark difference to MUC is that MIX requires support from both server that hosts the channel and user’s server. This is done to facilitate the notion that the user (and not particular connection or client application) joined the group and allows for greater flexibility in terms of message delivery (which can be send to one or many connections, or even generates notification over PUSH). Another important difference is the flexibility to choose which notifications from the channel user wants to receive (that can be messages, presence, participators or node information). In the most basic approach, when user decides to join a channel, it sends an IQ stanza to it’s own local server indicating address of the desired channel and list of MIX nodes to which it wants to subscribe. User’s server then forward’s subscription request to the destination, MIX server. As a result user receives subscription confirmation and from this point onwards will receive notifications from the channel, independently of it’s current network connection. Another essential bit of MIX is the reliance on XEP-0313: Message Archive Management to control message history and the complementary interaction between MIX server and user’s server. Main channel history is handled by the MIX server, but user’s that joined the channel will retrieve and synchronise message history querying their local server, which will maintain complete history of the channels that user has joined (based on the received notifications). This also means that even if the channel is removed, user is still able to access it’s history through local MAM archive (limited to time when user was member of the channel). As a result, chatter between client, client’s server and mix server is also reduced and unnecessary traffic is eliminated.
1.3. Benefits for mobile-first applications relying on push
All of this helps especially with clients that relay on constrained environment - be that unreliable network connection or operating system that limits time that application can be running. Because there is no dependency on the dynamic state of user presence/connection the issue with occupant leaving and (re)joining the room is eliminated - user gets the notification always. What’s more, thanks to shared responsibilities between MIX and user’s server, and the latter getting all notifications from MIX channel, it’s possible to generate notifications without relaying on workarounds (that most of the time are not reliable or impact resource usage).
In case of Tigase XMPP server it gets better thanks to our experimental filtering groupchat notifications feature, which allows user control when to receive PUSH notifications from group chats (always, only when mentioned or never)
1.4. Is MUC obsolete?
We think that MIX is the way forward, but we also know that this won’t happen overnight. Because of that MUC is still supported in all our applications and Tigase XMPP Server implements XEP-0408: Mediated Information eXchange (MIX): Co-existence with MUC to allow all non-MIX client to participate in MIX channel discussions using MUC protocol.
1.5. Tigase MIX Release Notes
Welcome to Tigase MIX 1.0.0! This is a feature release for with a number of fixes and updates.
1.5.1. Tigase MIX 1.0.0 Release Notes
This is the introductory version of MIX specification family
#mix-2:Implement XEP-0369: Mediated Information eXchange (MIX)
#mix-3:Implement XEP-0406: Mediated Information eXchange (MIX): MIX Administration
#mix-6:Create tests for MIX CORE & Participants Server Requirements
#mix-9:Add support for MIX-MUC integration
#mix-10:Invalid response for disco#items
#mix-14:Add configuration to limit who can create channels in component
#mix-15:NPE in MAMItemHandler
#mix-16:Add MIX to installer as option.
#mix-17:Could not parse new configuration of channel: PubSubException: Only participants and information nodes are supported!
#mix-18:NPE when sending requests to removed channel nodes
#mix-19:MAM:2 is not advertised
#mix-20:MIX component is broadcasting messages with bare JID
#mix-21:Possibility of duplicated subscription of a node
#mix-22:Nickname not returned in response after being set
#mix-23:Remove banned participants from participants list and subscriptions
#mix-24:NPE in MIXProcessor
#mix-25:Create MIX component documentation and publish it
#mix-26:Allow installation admins to manager MIX channels if domain admins are allowed
#mix-27:MIX-MUC message duplication
#mix-29:Weird “open channel” behaviour