[Standards] UPDATED: XEP-0369 (Mediated Information eXchange (MIX))

Kevin Smith kevin.smith at isode.com
Thu Aug 25 09:00:44 UTC 2016

On 23 Aug 2016, at 22:09, Dave Cridland <dave at cridland.net> wrote:
> On 23 Aug 2016 21:56, "Georg Lukas" <georg at op-co.de> wrote:
> >
> > Hi Steve,
> >
> > thanks for the clarifications. I'm still not quite sure about the
> > implications of some of the things though, maybe you can clarify...
> >
> > * Steve Kille <steve.kille at isode.com> [2016-08-17 17:33]:
> > > MIX permits three modes with MUC:
> > >
> > > 1.   No MUC.   There is no requirement to support MUC.   This may make sense for specialised implementations now, and more generally in the future.
> >
> > I anticipate that day. We are only some decades away from it ;)
> >
> > > 2.   MIX and MUC on separate domains.   This can work well for many environments, particularly where a limited set of clients are used, and where clients have good support for MIX/MUC co-existence.    A MIX domain may reference an associated MUC domain, which will help clients supporting this setup.
> >
> > I'd assume that this feature should be implemented by having the MUC
> > reference the MIX domain, and not the other way around. That would allow
> > interop between MIX and MUC users, as the MIX-capable clients can look
> > up the MIX JID when invited to an "upgradable" MUC.
> >
> > It doesn't make much sense to implement a MUC reference on the MIX JID,
> > because a MIX client will obviously use the MIX, and MUC clients won't
> > be able to obtain the MUC reference from a MIX JID.
> >
> I think it's needed to allow a MIX client to communicate a MUC jid to another client.

Indeed. Although maybe two-way references make sense, so that a MIX client invited to a MUC can know to join the MIX instead.

> > This would boil down to people communicating the MUC JID and smart
> > clients automatically upgrading to MIX, which has the same UX as #3
> > below, with a higher technical complexity on the client side.
> >
> No, it means that the common currency, as it were, is the MUC jid, not the MIX jid, and MUC becomes baked in for interop for decades.

Right. For MIX clients I think we want to be communicating about the MIX, and have the MUC interface cut out as much as possible.

> > > 3.   MIX and MUC on the same domain.   This will be trickier server side, and I do not think it makes sense to force servers to implement this.  You are right that this will improve migration and co-existence.   So for some servers, this may well be the right way to go.
> >
> > I think it makes sense to force servers that will support both MUC and
> > MIX to implement #3 as the default interop mode, as it will immediately
> > upgrade all MUCs on MIX-enabled servers to MUC+MIX, increasing the MIX
> > propagation significantly.
> >
> > Also, I'm not convinced that it will be really challenging on the
> > server-side, besides of the disco#list clash I outlined in my first
> > email. Could you (or server implementors) please provide the reasons why
> > this is going to be complicated?
> >
> I don't know.
> It's not wholly clear to me, yet, that a MUC interface onto MIX is going to be all that simple. I *am* certain that a MIX service needs to be written afresh, at least for Openfire, and a MUC interface to it needs to be written distinct from the existing MUC code.

I think this is likely true for M-Link as well, FWIW. There will be code re-use, but it won’t be a trivial interface on the existing abstractions.

> > > > 2. Use of client's bare JID
> > > [Steve Kille]
> > >
> > > A key design decision of MIX was to separate Presence and Messages.
> > > Users can register presence for multiple clients or none at all.
> > > Another decision was to make membership long term, so that messages
> > > get sent irrespective of presence.  A consequence of this is that
> > > messages HAVE to go to the bare JID.
> >
> > I understand the design decision to make MIX membership a long-term
> > thing bound to the user account.  However, by sending messages to the
> > bare JID you are introducing technical interop problems with RFC6121
> > message routing.
> >
> > The MIX XEP is currently not very clear in regard to this. If I am a
> > member of the MIX and subscribed my account to both presence and
> > messages, but haven't announced any presence, will the MIX service send
> > messages to my bare JID? Will it send presence packets?
> >
> > If yes, and my clients are currently offline, messages will land in my
> > account's MAM / offline storage, and presences will trigger error
> > responses to the MIX.

I don’t think this point about presences causing errors is right.

> If a non-MIX client is/comes online, that client
> > is going to receive (and fail to properly display) MIX messages sent to
> > the bare JID.
> >
> > If no, a MIX-enabled client needs to send some kind of trigger
> > (e.g. presence) to the MIX to start receiving MIX messages and
> > presences, so we could as well direct these stanzas to the client's full
> > JID.
> >
> We need PAM to be MIX-aware, basically.


> > > Using the roster to hold MIX JIDs is elegant and has some significant benefit.
> >
> > Could you please outline the benefits as compared to e.g. bookmarks?
> > This needs special handling in the client anyway (i.e. the client needs
> > to remember / disco#info / caps-check) all roster JIDs anyway to see
> > which are users and which are MIXes.
> >
> I'm not entirely sure it does. It'd be nice if it didn’t.


> > > To use MIX, clients have to support MIX and the servers they use have
> > > to support MIX (e.g.., PAM - XEP-0376).     So legacy clients are not
> > > going to see MIX stuff.
> >
> > Except for MIX messages that are sent to the bare JID and inadvertently
> > received by non-MIX clients. The only way to prevent this is by sending
> > messages to the full JID of MIX clients, which have to announce their
> > MIX-ability to the MIX.
> >
> Again, PAM needs to take care of this.

Yes. This hinges on the account having more ownership of things that are currently state held by each client.


More information about the Standards mailing list