[Standards] MIX Status (0.6.1), review, and Brussels Summit
georg at op-co.de
Wed Dec 21 13:26:09 UTC 2016
thanks for the reivew of the review, I'd like to add some more reasoning
to some of my arguments below.
* Steve Kille <steve.kille at isode.com> [2016-12-21 11:50]:
> You are right that a high bar has been set. [...]
> Operationally, I believe that this will be mitigated by server
> implementations that support both MIX and MUC, and following the
> procedures of section 7. This will enable transitional operation.
I agree, but this will only work out under two conditions:
1. we design MIX in a way that does _not_ completely break the usage of
MUC-only clients (this is also why I dislike the MIX-in-roster
2. we make it possible to run MIX and MUC-compat on the same domain
(everything else will force us to use the MUC JIDs as the primary
identifiers for chatrooms forever).
I don't see major roadblocks for either condition, so I'm also slightly
optimistic regarding the future of MIX.
> > We might need to codify how a MIX-enabled client connected to a non-MIX
> > server should behave (MUC fallback?).
> [Steve Kille]
> I don't think this is needed. A client can implement both MIX and
> MUC. The standards do not need to proscribe how this interacts in
> user experience.
While I tend to disagree on your last point, this is a topic for a
Either way, we SHOULD define how the client implementation should behave
protocol-wise, when a MIX-enabled client is connected to a server
without MIX-proxy support, and the user wants to enter a MIX.
> > ## Race Condition During Sync
> There is an issue here. Kevin Smith and Matthew Wild are discussing
> an approach to modify client bind in order to address this.
The client-bind modification is eagerly awaited. However it won't solve
the problem for MIX-MAM, unless we change the MIX spec to store the MAM
archive in the MIX proxy instead of the MIX service.
> I do not think there is any specific MIX issue, although I believe
> that MIX will be dependent on this new specification.
As long as we query the MIX service for our MAM, we need to create a new
atomic operation for query+subscribe to avoid race conditions. In the
current design, all messages get forwarded to the MIX proxy anyway, so
the operation needs to be atomic only between client and MIX proxy,
making it less of a problem.
One possible solution would be to extend the activation IQ with a MAM
sync anchor, another (as stated above) to store the MAM archive on the
user's proxy. There are probably more options, e.g. to ignore the race
condition and let client developers do the dirty work of history
My point is just that the current design is unclean in this regard, and
we are aiming at creating the best possible protocol.
> > I'm still not convinced it is a good idea to add MIXes to the roster.
> I strongly view that having MIX channels in the roster is a good
> thing. It allows presence to work for MIX using standard XMPP
Except that the MIX proxy needs to ('SHOULD') intercept presence anyway
and to only forward client presence to MIXes that the client has
It is really bad to have different specifications for presence routing
(based on roster subscription and a 'SHOULD') and message routing (based
on client activation).
We should promote the MIX client activation to a first-class citizen of
the XEP, and use its rules both for message and presence routing.
If we add MAM synchronization to the activation, we also elegantly solve
the race condition.
And if we decouple MIXes from the roster and instead maintain a
joined-MIX list in the MIX proxy, we win multiple things:
* no need to extend the roster format
* no need to query each contact whether they are a MIX
* we restore the user's ability to use pre-MIX clients on the same account
I think the main benefit of MIX-in-roster is to be able to add MIXes to
roster groups (and to rename them, though I'm not sure this is a good
thing, as it introduces interesting UX conflicts).
I'm not sure if this is really a demanded feature, and if we can't solve
it with less overall headaches.
> > Furthermore, the roster does not provide a way to distinguish MIXes from
> > regular contacts, unless the roster format is also extended.
> [Steve Kille]
> I think that for most clients/users this will not matter. It will be
> easy for me to distinguish MIX channels, and I would likely group in
> the roster.
It probably doesn't matter for the UX side, but it does for the
implementation side. If you put all MIXes into a separate roter group
anyway, there is no compelling reason to have them in the roster in the
> The client can easily work out if a roster member is a MIX channel and
> can "do clever things" if it wishes.
In the worst case, this requires a round-trip to the MIX, so the client
must defer important UI decisions (which icon to use, which context menu
to provide) until it receives the response from the respective contact.
From a client developer's perspective, this is a little nightmare that
should be avoided if any possible.
> > A client needs a way to obtain the list of all joined MIXes (e.g. from the MIX
> > proxy), so it can decide which MIXes to activate.
> [Steve Kille]
> I had pictured that many clients will take a simple approach of just
> activating all MIX channels.
That's simple, unless you also want to synchronize the MAM archive from
the respective MIXes.
> Another approach would be to tie to bookmarks, so that essentially you
> activate a MIX channel on startup if bookmarked.
I don't even want to get started about bookmarks, as currently deployed
and used for MUCs... If we want them to be used for MIX, we need to fix
> A client can find a list of MIX channels in which the user is
> participating from the roster. A MIX proxy command to list channels
> might be helpful in the future.
I would do it the other way 'round. Have the MIX proxy hold a list of
joined MIXes (it has to anyway) and expose that via an IQ.
> > Once the client sends activation, the MIX proxy could forward the
> > client's presence to the MIXes, so we don't need to put them onto
> > the roster for this either.
> This is a possible alternate approach. It puts some quite low level
> requirements onto the MIX Proxy and it feels to me preferable to use
> the roster and RFC 6121.
The MIX proxy is already in a situation where it needs to filter
messages and presence.
> I'm happy to put this onto the agenda for Brussels.
That would be great. Unfortunately, I won't be able to attend, but I
hope that the assembled community will find a nice and elegant solution
to all the open points.
> > [§5.1.8 client presence synchronization]
> I realised on review that the role of MIX proxy has not been written
> up. In most cases the MIX Proxy will hold current presence
> information and so when a client comes online, it can get this
> information from the MIX Proxy. I have added text to cover this.
Thanks, I've had a peek into the PR and I like the new wording.
We only need to keep in mind that the MIX Proxy sometimes needs to be
fully synchronized with the MIX channel as well.
> > ## Internal Consistency
> > The standard nodes in §3.7 have very different usage semantics. [...]
> This inconsistency has arisen for a number of good reasons, or more
> accurately because of the consequences and interaction of the good
I think it would be great to have another column in Table 3, that lists
the access method, i.e.:
Messages | | |Message Stanzas
Participants| | |PubSub
JID Map | | |PubSub
Presence | | |Presence Stanzas
> Detailed suggestions on sections to clarify are welcome.
I'll have another read of the XEP when it's published, and will try to
create a wording-related PR.
> > ## MUC Interop
> I am not convinced that implementing MUC and MIX on the same domain is
> viable. It is certainly not going to be easy. Your note points out
> an issue.
Just to clarify: I'm not speaking of a full MUC implementation running
on the same domain as a MIX implementation, but of a MUC interop layer
to access the MIX service, to allow MUC-only clients to participate in
MIXes. It could be implemented in the MIX proxy or in the MIX service,
and it does not need to implement the full MUC protocol.
> My recommendation would be to not allow this and to require MIX and
> MUC domains to be distinct. I suggest that we discuss in Brussels.
I can understand that it makes the server/service implementation more
complicated, but it will significantly improve the MUC-to-MIX migration
UX. The compatibility/UX issues I outlined in September
are still valid, as far as I can see.
I think you need to bring up the topic in Brussels, and the first
decision that needs to be made is which UX we want to create, not which
technical implementation is easiest to do or even most elegant.
The UX of XMPP is so bad that we are bashed by the IT crowd whenever
anything messaging-related comes up. We can make the best and nicest MIX
XEP, and it won't be used by anyone if we don't focus on the UX first.
Therefore my favorite is still #4 from the referenced email, where MIXes
can be accessed using the MUC protocol on the MIX domain from a MUC-only
> > ## Joining a MIX
> I think that in 24, it is desirable to use a JID that matches the real jid, as part of the client confirmation.
I can't see how having the client's bare JID reflected in an IQ respsone
makes any sense.
> In practice, there is little reason for a client to need to know their
> own proxy JID. So I don't see a need to extend the protocol. A
> client can easily find proxy JID by matching their own NICK in the
> participants list.
The client needs to know their own proxy JID because it is the sender
JID of reflected messages. It is also not easy to find their own proxy
JID based on the NICK because the NICK is optional.
If we have a JID field in the <join> stanza, we should use it for the
proxy JID (and rename it appropriately). That spares us another
roundtrip, doesn't force clients to subscribe to the participant node
and makes message matching easier.
> > ## Converting a 1:1 Chat
> Ah yes, there are some issues here. I have updated. Let me know
> what you think of the new text.
I've started a separate discussion about the general UX and security
implication of the conversion.
Regarding message history, it might be good to re-use XEP-0297: Stanza
Forwarding, instead of creating a new <resend> element.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 811 bytes
Desc: Digital signature
More information about the Standards