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.

1. Overview

Tigase MIX component is a component extending Tigase PubSub Component and providing support for XEP-0369: MIX protocol extensions being part of MIX specification family.

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:

In addition to the above extensions, there are several other that are optional:

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

1.5.1. Tigase MIX 1.1.0 Release Notes

  • Added support for mam2#extended; #mam-73

  • Fixed issue with joining MIX channel using MUC; #mam-74

  • Fixed issue with rejecting incomplete data forms for channel configuration; #mix-31

1.5.2. Tigase MIX 1.0.0 Release Notes

Major Changes

This is the introductory version of MIX specification family

All Changes

  • #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-8:Improve caching

  • #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-28:NPE in Affiliations.getSubscriberAffiliation

  • #mix-29:Weird “open channel” behaviour