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.