[Standards] MIX Status (0.6.1), review, and Brussels Summit

Georg Lukas georg at op-co.de
Mon Dec 19 23:41:33 UTC 2016


* Steve Kille <steve.kille at isode.com> [2016-12-05 16:25]:
> Careful expert review and work on initial implementations is going to raise
> issues that will lead to updates.

Thanks very much for your work so far. I've finally worked through the
XEP and will try to organize my points a bit.

# General issues

## Required Software Support

Generally, we are putting up a very very high bar by requiring support
from all of the user's clients, their server and from the MIX service.
Let's hope adoption is faster than with other XMPP sub-protocols.

§3 item 13: "[...] where a user chooses to use MIX, all of the users
clients need to support MIX."

§3.3 item 1: "[...] MIX messages will only be sent to clients that
support MIX."

I think §3 item 13 needs to be updated and it also needs to mention that
the user's _server_ must support the MIX proxy functionality.

We might need to codify how a MIX-enabled client connected to a non-MIX
server should behave (MUC fallback?).


## Race Condition During Sync

With the introduction of MAM, we have created a very interesting
protocol combination (carbons, offline messages, MAM synchronization)
which is almost impossible to do right. Depending on the order in which
a client executes the queries, there will either be a moment for which
it will not receive any messages, or for which it will receive
duplicates.

§3.3 item 5 introduces the same race condition with "The MIX Proxy will
only send messages to online clients and will discard messages if no
clients are online. This means that a MIX client needs to resynchronize
with the MIX service when it comes online. This synchronization will
happen directly between the MIX client and MIX channel."

With MUC, at least we had a cleaner synchronization protocol where the
client could identify the last received message and request anything
after that (though using the timestamp for this sync surely isn't
appropriate any more).

I have no idea how to elegantly solve this problem for messages. For
presence, it seems to be solved in §5.1.8 by using a client's outgoing
presence as the synchronization point.


## Subscription and Presence Management

I'm still not convinced it is a good idea to add MIXes to the roster.
In theory this gives automatic forwarding of presence to the MIX. In
practice, a client needs to send a MIX activation (§6.1) anyway.

Furthermore, the roster does not provide a way to distinguish MIXes from
regular contacts, unless the roster format is also extended.

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. 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.


§5.1.8 "When the full JID of a client is added to the MIX channel
presence node and that full JID is not in the presence list, the MIX
channel will send to the client presence for all of the items in the
presence node using standard presence stanzas." -- this approach has a
significant drawback we already have in some MUC implementations. If the
MIX thinks that the client is still "joined" (i.e. presence from this
client is in the MIX presence table), it will not provide a full
presence list to the client. However, a c2s disconnect or an s2s
disconnect can lead to the client becoming desynchronized, requiring a
full presence list.

My current approach to the full-resync in MUCs is to send a
<presence-unavailable/><presence-join> to the MUC, which is a horrible
hack. We should provide something better for MIX.


## Message Routing

As soon as a user joins a MIX, their MIX proxy will receive copies of
all MIX messages. If the user becomes frustrated with XMPP, disconnects
and uninstalls their client, the XMPP server is doomed to receive and
drop MIX messages from all joined MIXes forever. This might cause
significant traffic and processing overhead to public XMPP servers once
MIX lifts off.

It would be good to have a better solution to this problem, e.g. by
having the MIX proxy forward activation+presence to the MIX channel, and
a MIX channel to only send messages to activated proxies.

Maybe it is possible to solve this together with the MAM race condition
in an elegant way that I don't see.


## Internal Consistency

The standard nodes in §3.7 have very different usage semantics. Some are
accessible via PubSub, some forbid PubSub. Others can be accessed
directly via presences, other via messages, others via MAM. It would be
great to have more consistency in the spec. Second to that, it would be
nice to have the possible access mechanisms explicitly stated in the
individual sections, also saying which parties (client / MIX proxy / MIX
service) interact with each other.


## MUC Interop

The XEP is stating that a MIX service may implement a subset of the MUC
protocol on the same domain.

However, a MUC channel and a MIX channel react differently to disco#info
and disco#items. While the disco#info response could include both the
MIX and the MUC data, MUC disco#items is specified to return a list of
participants, whereas MIX disco#items returns the list of nodes.

To allow interop, it would be great to use a different xmlns for the
list of MIX nodes, e.g. "urn:xmpp:mix:0#get-nodes". maybe it would even
be sensible to merge the nodes list with channel-info, so that a client
can obtain both with a single query.


## Joining a MIX

The current join protocol has two drawbacks:

1. there is no way for a client/proxy to obtain their proxy JID. The
join response (example 24) has a 'jid' element which could be used to
return the proxy JID.

2. there is no way to specify the nickname while joining. Another
roundtrip is needed for that (§5.1.5), and the MIX service can not
publish the nickname in the first participants node update (ex. 26).


## Converting a 1:1 Chat

§5.5.4 "It may also be useful to share some or all of the messages from
the 1:1 discussion into the new channel. This is done by sending these
messages to the channel." -- it is not clear which client is responsible
for sending these messages, and how author attribution is to be
preserved.



# Wording

The XEP is hard to understand because it is not using a consistent
wording. It would be great to have another editorial run and to use
consistent terms everywhere ('user' and 'server' are ambiguous; it is
not always clear which tasks are performed by the client and which by
the proxy, and if the user's server or the MIX server is meant). I would
suggest to write 'MIX service' instead of 'MIX server' and to only use
'server' for the user's XMPP server (or even better 'MIX proxy').


§3.3 item 2 "MIX client sends these MIX management queries to the MIX
Proxy using the clients full JID" - is this describing the 'from' or the
'to' JID? 'from' is always the full JID anyway, and for 'to' this
doesn't make much sense.


§3.6 the paragraph after table 2 ends with "the mapping between real JID
and proxy JID MUST NOT be changed," - there should be some more text?

§3.7.10 are the "bare JIDs" mentioned there proxy or real JIDs?

Table 8: The default value for 'JID Visibility'	should be 'Default'

§5.1.7 "Presence updates are sent out to subscribing using standard
XEP-0045 compatible presence stanzas." -- what are XEP-0045 compatible
presence stanzas? Presence like in RFC6121? Presence with a MUC element
(<x xmlns='http://jabber.org/protocol/muc'/>)?


Thanks & kind regards,

Georg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 811 bytes
Desc: Digital signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20161220/99ffbea9/attachment.sig>


More information about the Standards mailing list