[Standards] UPDATED: XEP-0369 (Mediated Information eXchange (MIX))
georg at op-co.de
Wed Aug 17 11:05:43 UTC 2016
* XMPP Extensions Editor <editor at xmpp.org> [2016-08-16 12:33]:
> Version 0.2 of XEP-0369 (Mediated Information eXchange (MIX)) has been released.
Thanks to everybody involved! Let's get this one moving fast, now! :)
I like the overall design, but I think some aspects of it can be
1. Sharing a domain between MUC and MIX
I think this is imperative for easy coexistence and upgradeability from
the current MUC infrastructure to using MIX. We should explicitly
support accessing the same chatroom via both protocols under the same
JID: This will make the UX much smoother and spare us the pains and
debugging problems of a hidden actual service JID that needs to be
communicated between MUC-vs-MIX clients. I would even ask for allowing a
user to use a MIX and a MUC client at the same time, sharing a nickname.
From the protocol side, the only clash I can see is disco#items on a
room JID, which returns the participant list for MUC, and the supported
nodes for MIX. I'm not sure if there is an elegant way to discriminate
these use cases with the query (Have a separate well-known query JID for
MIX nodes? Add a custom element to the iq-get? Have some namespace for
the query? Return both MUC participants and pubsub nodes?), but I would
be ready to settle with a less elegant solution for the sake of better
UX and interop.
2. Use of client's bare JID
Sending of presence and message packets to the user's bare JID is going
to break things. First, message routing is server-defined, and will
cause different behavior on different servers. Second, a client with a
negative presence priority will not be able to receive data from MIX.
Third, messages and presence stanzas will end up routed to clients that
do not support MIX or do not know which channels the user is on, causing
weird UX issues. Fourth, client authors will have to implement and
enable carbons, and handle carbonated MIX messages like regular MIX
messages (whereas carbonated private messages might have slightly
different semantics). Fifth, these messages will end up in the user's
offline storage, probably confusing a later resync.
As not all clients are going to implement MIX overnight, the protocol
should not force new types of messages onto legacy clients. Therefore I
propose to make MIX participation more explicit:
a) always use the client's full JID to send MIX related stanzas
b) require a MIX capable client to explicitly send directed presence
to all MIX rooms it is interested in (§5.1.6 is okay in this regard,
though I'd like to see an explicit extension element akin to MUC-join;
a dumb client could just put both MUC and MIX extensions into a presence
packet and see what comes back ;-)).
c) As a consequence, MIX JIDs should not be part of the user's roster. I
don't particularly like the alternative (bookmarks), but it still sounds
better to me than breaking legacy clients.
d) As another consequence, the MIX service would send copies of a MIX
message/presence to each client of each user, instead of only once per
user. However, this will avoid the mess that RFC6120 message routing +
3. Message tracking
Initially, MIX messages were going to be handled like pubsub events. The
text in §5.1.11 still claims so (I suppose this is an overlooked
remnant). Example 30 shows a regular message with a rewritten 'id'.
I'm still strongly in favor of having a stable way for a client to
identify a reflection of an outgoing message, as discussed in .
If we use MAM, reflected messages should be identified by their MAM
archive id, allowing for a later follow-up sync. However, client-
originated messages are not identifiable with this approach, and it
would be great to have the original packet ID reflected, or at least an
additional element with the original packet ID, so that the client can
mark the message as "delivered".
4. Capability Reduction
I'm not quite sure why MIX allows to register a service-wide nickname,
but passwords and voice control got kicked. Personally, I would also
kick the nickname registration feature: IMHO it doesn't make very much
sense in a federated environment where most chat rooms are distributed
over different service domains anyway, and where the real JID is the
only reliable identifier anyway.
While we are at it, I don't like the idea of proxy JIDs very much
either, and I'd rather have gone with the MUC-light proposal of just
using users' real JIDs everywhere. It would make the implementations
much easier and less error-prone... And we are living in a post-privacy
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 811 bytes
Desc: Digital signature
More information about the Standards