[Standards] UPDATED: XEP-0369 (Mediated Information eXchange (MIX))

Georg Lukas georg at op-co.de
Tue Dec 5 20:03:34 UTC 2017


so I finally found the time to recover my notes for the first half of
MIX, and to get through the second half. Notes below :)

§3.2 Core Concepts

| 13. Although some protocol is shared with MUC, MUC clients are not
|     interoperable with a MIX service. This means that where a user
|     chooses to use MIX, all of the users clients need to support MIX.

Is that still a requirement / concept?

§3.9.1 Roles

| Administrators, Participants, and Allowed MAY NOT have any members.

There is no "MAY NOT" in RFC 2119, and this is probably a typo anyway.
Probably "MAY be empty" would be better?

§3.9.4 Participants Node

| When a user joins a channel, the user's bare JID is added to the
| participants node by the MIX service.

From context, this should be the user's bare proxy JID.

§6.1.1 Joining a Channel

When I join / leave a MIX channel with one of my clients, I would like
to know what happens to my other clients, i.e. what kind of information
do they get (roster push? pubsub notifications?). It would be great to
have according text in the XEP, plus examples of the anticipated XML -
as a client developer, I need to cope with a situation where I will
receive seemingly unrequested data.

§6.1.5 Setting a Nick

How are other channel participants informed about a nickname change? Do
they have to subscribe to the Participants node? Or will there be a
presence update (§6.1.7 has a presence example that contains the

When the user joins, they don't have a nickname at all, it is only
assigned with <setnick/> - does that mean each join causes two
Participants updates - one with the proxy JID and another one with the

§6.1.8 Client Coming Online and Obtaining Presence from the Local Server

| Presence updates will continue to flow to the user's local server, and
| so the local server is able maintain up to date presence state for the
| channel.

Does that mean that a server must keep a cache of all client presences
of all participants of all MIXes of all users? Even if the local user
abandoned their account a long time ago? That sounds like you could DDoS
an XMPP server by registering an account, joining a large number of
large MIXes and causing significant ingress traffic.

§6.1.12 Going Offline

| The MIX channel will notify subscribers to the presence node of the
| user going offline by sending a presence stanza to the full proxy JID
| of each client.

I suppose here it's actually the full JID and not the proxy JID ;-)

§6.1.14 Retracting a Message

The <retract> element references the message ID - not the MAM ID. I'm
not sure what the time frame is where it is allowed for a client to
retract, and whether the <retract> message will be reflected to all MIX
participants or only stored in MAM (and which ID will be contained in
the reflected retraction). If I want to retract a message I sent from
another client / before a client restart, do I need to persist the
original message ID now (and so does the MIX service)?

Maybe we should move Retraction into its own XEP as well? Or maybe use
Last Message Correction for that, instead?  (Though LMC also relies on
the message ID, which I consider unfortunate if we also have

§6.1.16 Inviting another User to join a Channel that the user does not
        have Permission to Join

I like the principal protocol here, though I think it would be
acceptable to remove the <inviter> and <invitee> elements from the
<invitation> element. The server needs to verify the JIDs anyway and can
not rely on what is passed by the invitee (but it could encrypt the
fields into the token).

I'm not sure if the inviter needs to bind the invitation to a given
invitee JID or if an "unbound" invitation would be acceptable - but
there is really no technical need to carry on the <inviter> field.

§6.1.17 Sending Private Messages

I think we need to get rid of ressource locking for messages, and that
the receiver's server always needs to forward the message to all
MIX-joined (or maybe even MIX-enabled) clients. It would make the table
less complex because there would be no more need to distinguish between
"first" and further messages.

It might also make sense to explicitly state the message types that are
allowed to be sent as private messages (everything but 'groupchat'? Only
'chat' and 'error'?)

§6.3 Ensuring Message Delivery

| When there is a long term connection failure, the MIX channel will
| receive an error from the XMPP server indicating that a message failed
| to transfer to a recipient.

Unfortunately, there is no guarantee that 'groupchat' messages will be
bounced on error. It might be better to have a mechanism that lets the
user's server know about a network outage and allows it to MAM-sync from
the MIX channel archive.

§6.5.2 Creating a Channel

I would suggest to change the wording from "channel name" to "channel
identifier" and to explicitly state that this will become the local-part
of the channel JID. A channel _name_ might as well mean the
human-readable free text field that is returned as the identity name
field to disco#info.

There might be merit in letting the client also define this identity
name at the same time when creating a channel.

§6.5.4 Converting a 1:1 Conversation to a Channel

There are two security implications when forwarding message history.
First, it would expose private/encrypted/sensitive messages to the MIX
service. Second, there is no way to verify the authenticity of the
messages, so the sender could easily fake a conversation history.
A joining client now needs to distinguish normal messages from
messages-forwarded-by-somebody in the UI to make that clear to the user.

| ... MAY be sent by either the user creating the channel or the 1:1
| chat partner at any time subsequently.

A malicious MIX participant could use this mechanism to inject fake
messages at any time. After finding out the hard way that a dozen client
implementations failed to check the source of Carbons [0], I consider
this feature as highly problematic.

§8. Supporting MIX and MUC together

Thanks very much for making the fully integrated approach compatible and
supported. Now, can we remove the partially integrated one, please? It
adds complexity to the protocol and to clients, and it really has no
benefit over the fully integrated one, except maybe as a short-cut for
server implementations.



[0] https://rt-solutions.de/en/2017/01/cve-2017-5589_xmpp_carbons/
|| http://op-co.de ++  GCS d--(++) s: a C+++ UL+++ !P L+++ !E W+++ N  ++
|| gpg: 0x962FD2DE ||  o? K- w---() O M V? PS+ PE-- Y++ PGP+ t+ 5 R+  ||
|| Ge0rG: euIRCnet ||  X(+++) tv+ b+(++) DI+++ D- G e++++ h- r++ y?   ||
++ IRCnet OFTC OPN ||_________________________________________________||
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20171205/c0437cc5/attachment.sig>

More information about the Standards mailing list