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.

2. Configuration

Configuration of MIX component is extended version of PubSub component configuration. We will not describe here configuration of PubSub component as it already available in PubSub component documentation.

2.1. Setting ACL

With ACL you can control who can create publicly visible channels and also ad-hoc channels. ACL properties accept following values:

ALL

Anyone can create channel

LOCAL

Only local users can create channels (from all local domains on all local domains)

ADMIN

Only installation administrator can create channels

DOMAIN_OWNER

Only domain owner of the domain as the domain under which MIX component is running can create channels

DOMAIN_ADMIN

Only domain administrator of the domain as the domain under which MIX component is running can create channels

DOMAIN

Only users from the same domain as the domain under which MIX component is running can create channels

2.1.1. Setting ACL for creation of public channels

Property name: publicChannelCreationAcl

Default value: DOMAIN_ADMIN

By default we allow only local domain owners or admins to create publicly browsable channels.

Allowing domain users to create public channels
mix () {
    logic () {
        publicChannelCreationAcl = 'DOMAIN'
    }
}

2.1.2. Setting ACL for creation of ad-hoc (private) channels

Property nmae: adhocChannelCreationAcl

Default value: DOMAIN

Allowing all local users to create public channels
mix () {
    logic () {
        adhocChannelCreationAcl = 'LOCAL'
    }
}

2.2. Disabling support for MUC

MIX component by default exposes MUC compatibility layer for clients that doesn’t support MIX yet, so they would still be able to participate in the MIX channel conversation. It’s possible to disable it with the following option.

Disabling support for MUC
mix () {
    roomPresenceModule (active: false) {}
}

2.3. Setting limit of cached channels

Property name: maxCacheSize

Default value: 2000

MIX component is caching channels configuration and affiliation in memory while it is processing request for the particular channel. To make that more efficient it is using cache to keep the most often used channels configuration in memory instead of loading it every time.

You can increase this value by setting maxCacheSize property in the config scope of the MIX component:

Setting limit of cached channels
mix () {
    config () {
        maxCacheSize = 3000
    }
}