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

Philipp Hörist philipp at hoerist.com
Thu May 10 08:59:13 UTC 2018


Im interested in implementing it in Gajim

It would be nice if someone could share the domains where a server
runs that offers some kind of MIX impl.

regards
Philipp

2018-05-10 10:36 GMT+02:00 Steve Kille <steve.kille at isode.com>:
>
> 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
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe at xmpp.org
> _______________________________________________


More information about the Standards mailing list