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

Kevin Smith kevin.smith at isode.com
Fri Mar 23 20:57:41 UTC 2018

Thanks for the review, comments follow (I’ve elided trivial points).

On 20 Mar 2018, at 16:34, Florian Schmaus <flo at geekplace.eu> wrote:
> As of now MIX is bloated and got way out of hand.

I’m not sure to what extent this is true, but I’m going to go through and see what can be simplified. MIX is a very simple core concept, and I’m not entirely sure how we’ve got to the current situation where it’s viewed as complex - but there is certainly some stuff in XEP-0369 that doesn’t need to be when we move towards ‘xmpp2' routing rules.

> I am sceptical if using messages with type 'groupchat' is a good
> decision.

I do think this one is worth keeping. Dave provided some useful thoughts here.

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

This is true, but under the ‘xmpp 2’ routing rules of stuff that’s bare-JID being both archived and distributed this would be ok.

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

I think the protocol works without this in principle, but it's desirable. In the vast majority of cases you want your presences to be tied together and don’t want to have to manually send presence to every joined channel, either on login or on change. MIX would continue to work ok without it, but at the cost of much more complexity in the clients (see MUC where we need presence repeaters in the clients, bookmarks, etc. that go away with a simple server feature), so this is somewhere I’m keen we don’t go.

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

I think you’re right and this isn’t particularly onerous - this level of indirection is something we’ve coped with just fine in MUC since before MUC, and doesn’t cause issues in practice. I’ll look at how the JIDmap works in MIX and check that we’re not adding more complexity here than we need to be, given that this was simple in MUC and should be simple in MIX. One option is for us to rip out the complex bits (which are mostly around the ability to opt out of possible future changes, and to have jid-hidden rooms but say you want to be jid-visible and stuff) and leave those to be specified elsewhere, and just leave the much simpler core in.

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

Some words here are worthwhile.

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

I think this can go away entirely, and instead reference ‘XMPP 2’ rules once they’re published, as this just follows from that.

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

Will review, thanks.

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

I don’t think that particularly matters - although 2119 keywords are often capitalised and capitalised words are often 2119 keywords, neither is necessary. This is a straightforward change to avoid the confusion, though.

> "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?

Will review. One reason for backing the data onto nodes is that it allows MAM queries for resync, which may or may not be something about which we care - but as things stand this doesn’t work for presence because it’s sent as an initial flood anyway (ideas on that one without adding complexity are welcome :)).

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

Almost certainly :)

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

Or we remove some of the redundant layers of wrapping around pubsub items in MAM, which is something we should consider.

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

I think we need to reconsider this - possibly removing it from 369 until we’ve done so. I suspect the best thing to do here is some sort of ‘subscribe one MAM archive to another’ protocol to ensure the user’s server resyncs later.

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

This is something that has always been possible, and shouldn’t cause issues with caps. If it does with caps2, we need to fix it.

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

I think probably 6.5.4 needs to be broken out and treated in more detail elsewhere.

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

Yes, clearly wrong, ta.


More information about the Standards mailing list