[Standards] Thoughts on MIX adoption (and will MIX ever happen?)

Steve Kille steve.kille at isode.com
Thu May 10 08:36:17 UTC 2018


Having made the latest round of MIX edits,  I felt it was time to share some
thoughts on MIX.    

It has been a number of years since work was started on MIX, and
implementations are thin on the ground.  It seems sensible consider when and
if this will change.

There are a number of reasons why MIX take-up is likely to be slow:

1.  It is a big spec to implement for either client or server, even for a
server with a good MAM and PubSub base.

2.   The is a chicken/egg situation with clients and servers.  A server
implementor will wait until MIX clients are available and vice versa.

3.   This does not appear to be an exciting new service (but see later).   A
simple view of MIX is that it is just a different way of providing an
existing service, so there is not simple customer benefit or drive for MIX.

4.  MUC broadly works.   There are lots of little things broken, but there
is no major issue to force replacing it.

5.   MIX needs a migration.    This will inherently slow things down and
inhibit starting stuff.

6.   Some in the community are working to address issues by updates to MUC.
>From my perspective, this is "string and duct tape" and is not addressing
deeper problems.     Such activity will delay MIX.

7.   Related to the above, some feel that MIX is just too much, and this
definitely creates a feeling of "will MIX ever happen?".


Predicting the future is hard, but.....

Isode is committed to both server (M-Link COTS product) and client (Swift
free & open source) implementations of MIX.   We have strategic reasons to
do this, particularly because of requirements on constrained networks.   We
have lots of other things we also need to do, but MIX is going to happen in
our product set.

It may well be that others will produce general purpose MIX implementations
first (e.g., Surevine), but let's suppose this does not happen.

It seems conceivable that MIX will end up as a specification that is useful
for specific purposes, but not widely implemented (e.g., like XEP-0365).

However,  I do not think this will happen, as MIX has many benefits.  I
think that initial implementations will encourage others, almost certainly
gradually at first.    Once there are a few implementations, more will
follow.   Then MIX will be seen as something that modern XMPP
implementations need to have and other implementations will play catch up.

Let me justify this in terms of MIX benefits that I see:
   - Some of the broken bits of MUC that we all live with will become much
clearer as MIX starts to be used.  There will be a "how did I ever live with
that" experience
   - Multi-client will become more important, and MIX will avoid a slew of
MUC problems
   - "proper" history support will add value
   - Message only option will be important for constrained bandwidth and
will facilitate observers (avoiding "presence clutter" from observers
   - As we work to build richer multi-user communication, with shared files,
shared pictures, comments and likes, MIX is going to be the building block
we need (that MUC is not)

I do not think that this is going to happen quickly, but my  (biased) bet is
that MIX is going to happen



Steve












More information about the Standards mailing list