[Standards] Review of XEP-0369: Mediated Information Exchange (MIX) v0.9.5

Florian Schmaus flo at geekplace.eu
Tue Mar 20 16:34:41 UTC 2018

As of now MIX is bloated and got way out of hand. It is a prime example
for a standard that grew enormously without implementations following.
At some point in the past I hoped that the authors would split MIX into
a mandatory to implement but slim core specification and an add-on XEP
with the optional features. Unfortunately that never happened and
ideally it would have been done from the very beginning.

I am sceptical if using messages with type 'groupchat' is a good
decision. First, sending type 'groupchat' messages to bare JIDs usually
causes a stanza error reply as per RFC 6121 § "For a message
stanza of type "groupchat", the server MUST NOT deliver the stanza to
any of the available resources but instead MUST return a stanza error…".
Given that MIX requires support of the participants server, this is an
override of this rule which should at least be clearly stated in the XEP.
But more importantly, traditional XEP-0045 groupchat messages are often
not stored in the user's archive, while MIX messages need to be.
And there is no technical reason for MIX to use type 'groupchat'
messages. In fact, the type of MIX messages is  irrelevant, as MIX
requires the XMPP-RFC routing rules to be overwritten in every case.
Hence I'd simply use 'normal' / "no type specified" messages.

Two controversial points about MIX are "channels in roster" and "JID
hidden channels".
For the former I'd like to see some motivation in the XEP *why* we need
channels in roster, which probably becomes an explanation why users
should be subscribed to the channels presence and vice versa. If there
is no good technical reason for doing so, then I'd suggest that we drop
that. Clients still could display channels next to the roster, like some
already do with MUCs.
For the latter I feel like the jidmap and proxy JID does *not* add
unjustifiably much complexity to the XEP while I believe that there may
be situations where you want to hide your JID. On the other hand I could
life without that future too (and it would make MIX way easier to
implement). Ultimately it would be great if support for "JID hidden
channels" could be an optional part of the spec, but I didn't came up
with a good approach allowing this (yet).

With MIX I now get a real presence flood after sending my available
resource, including presence from JIDs not im my roster (thanks to MIX
JID construct foo#bar at mix.example/resource). The situation is similar
with MUC, but only after explicitly joining the channel. I'd like to see
the XEP at least discussing the situation, to make the implementer aware
of it.

§ 3.5
"All MIX messages received by the MIX participant's server for a
participant MUST be stored using MAM in the participant's archive.". It
seems to be a fundamental design idea of MIX that the primary archive of
channel messages is the one of the participant. While this distributes
the load of a single channel across multiple archives, I don't see a
reason why this is a hard requirement. I would at least s/MUST/SHOULD/ here.

§ 3.9.7
"A MIX channel MAY require that all participants publish presence." Why
is that an option? How could that be enforced? By having the participant
to accept a presence subscription request from the channel? If so, then
this should be clearly stated.

Nit: "and NOT using pubsub protocol." 'NOT' is not a RFC 2119 keyword.

"Clients MUST NOT directly access the presence node using pubsub." I'm
confused, then why have we the node in the first place? Just so that
entities can subscribe to it and receive presence? If so, what is the
point of having Example 3? But if we already put the MIX channel in the
roster, then why can't we simply use standard presence subscription
(requests) instead and drop the presence node?

§ 6.1.2
Adding the channel to the roster triggers a roster push after <join/>.
It is not specified if the pushed roster item is MIX annotated or not.
It possibly should be annotated.
Nit: Possibly s/no presence information is sent about the MIX channel to
the user./no presence information about the MIX channel is sent to the

§ 6.1.4
Nit: Example 37 is missing the 'xmlns' attribute and usually <items/>
always has exclusively direct <item/> children.

§ 6.1.10
There is probably no way we could make Example 48 less complex without
dropping support for proxy JIDs and the jidmap, but it should be at
least uniformly indented. As it is right now, it is pretty scary.

§ 6.1.14
Nit: "<id> attribute" should be "'id' attribute"

§ 6.1.16
Nit: "checks with disco" sounds a little bit to informal.

§ 6.3
The approach specified herein is fragile and prone to duplicate or lost
messages (especially if SM is not used on s2s). The main design flaw is this
When this happens, the MIX channel MUST take responsibility to ensure
that the message is retransmitted and delivered.
Instead the protocol should exploit the fact that not the MIX channel
but the participant's server has an greater motivation to provide its
user a gap-free groupchat experience. Therefore I suggest shifting most
of the responsibility from the MIX channel to the participant's service.
That is, instead of "MIX channel MUST take responsibility to ensure that
the message is retransmitted and delivered.", the MIX channel simply
sends the marker to the participant's service, upon which the
participant's server re-syncs its archive with the MIX channel archive
(e.g. by using MAM). Note that this reassembles the invaluable design
idea of djb's Internet Mail 2000 and StubMail somewhat.

Furthermore, the participant's service could periodically query the MIX
channel for its last message ID and total message count, re-syncing,
possibly using bisection, if both don't add up.

Example's 65 response could be simply an empty result IQ.

§ 6.5.1
It appears dangerous to announce features depending on who asks. This
could cause all sorts of troubles, for example with ecaps/ecaps2.

§ 6.5.4
Suddenly talks about MUCs (possibly a copy and paste error). And a good
candidate to factor out into an add-on XEP.

§ 6.5.7
Example 72 response is missing <item/>.
Example 73 is missing <item/>.

§ 6.5.8
Example 74 is missing <item/>.
Example 75 is missing <item/>.
Getting PubSub right is sadly hard.

§ 7.2
"The participant's server MUST NOT make any other modifications to each
message." I think the server will possibly at least inject a MAM-ID
using <stanza-id/> into the message. Thus the strong normative wording
seems wrong here.

Further Nits
- Example 44 has broken indentation
- Example 46 has broken indentation
- s/$gt;/>/
- Some PubSub examples violate XEP-0060 § 7.1.1.: "Depending on the node
configuration, the <publish/> element MAY contain no <item/> elements or
one <item/> element."

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 642 bytes
Desc: OpenPGP digital signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20180320/4bc76a58/attachment-0001.sig>

More information about the Standards mailing list