[Standards] Proposed XMPP Extension: Mediated Information eXchange (MIX)

Georg Lukas georg at op-co.de
Tue Jan 26 12:07:23 UTC 2016


Hi,

* XMPP Extensions Editor <editor at xmpp.org> [2016-01-06 11:14]:
> The XMPP Extensions Editor has received a proposal for a new XEP.

It's really awesome to see MIX going forward. As I haven't participated
in the last summit and won't be able to come to Brussels, I'd like to
write down my questions and feedback in yet another long email, in the
hope that the points can be discussed/addressed this week. Maybe some of
them were addressed already, but didn't find their way into the XEP yet.

MUC Interop
-----------

1. Use same service JID for MIX and MUC: Parallel MIX/MUC operation is a
designated goal, however the intro states that MIX and MUC SHOULD be
hosted on different domains. I would like to ask the committee to revise
this decision, altering the underlying protocol if required. XEP-0030
allows returning multiple 'identity' elements in a disco#info response,
so I can not see a reason not to return both MUC and MIX identities on
the same domain. On the other hand, I would consider interop (especially
handling of invitations between MIX and MUC clients) to be much easier
if the access protocol for the chatroom is not encoded in its JID.

2. Invitations: this isn't ready, obviously, but it needs to be able to
handle all combinations of MUC and MIX transport between the inviter and
invitee.

3. If #1 can not be addressed: the intro states "The MIX service SHOULD
include a reference to the MUC mirror". This should be extended to
recommend references in both directions, so a MIX client receiving a MUC
invitation can upgrade to the MIX.

Registration and Presence
-------------------------

4. §5.1.2 "Registering with a MIX Service" defines a new use case
that was not available in MUC, without a clear rationale / use case.
IMHO registering a nickname on a server has only little value, as for
most IM users the chatrooms are distributed over many different
services, and non-anonymous rooms will probably be in use where stronger
authenticity of users is needed (i.e. corporate environments). If a user
wants to register a nickname with a chatroom OTOH, this is already
accomplished by <join/> in a more transparent way. I would suggest
completely removing §5.1.2.

5. §5.1.3 "Coming Online" and Presence Reflection / MAM: from the
example it looks like each client's presence update is published as a
separate event by the MIX service. When a new client is coming online
and wants to obtain the current list of present users, does it need to
load the whole history of presence events, starting with day 0 and
mostly containing stale presence changes that were overridden by later
updates, or is there some aggregation / shortcut, like only keeping the
latest presence event per full-user-JID? If instead there is a "current"
event that contains the set of all currently online presences, we still
need to have differential updates after that, so that a client is not
flooded with redundant traffic in a large MIX. The same problem exists
to a smaller degree for joins/leaves in the participants list.

6. §5.1.4 "Going Offline" needs to work in the case when the user's
session is terminated unexpectedly. By normal presence processing rules
this is only the case if the MIX JID is on the user's roster or if the
user sent a directed presence to the MIX during that session. Therefore
§5.1.3 "Coming Online" should be switched to using directed presence as
well (maybe in a way comparable to / compatible with MUC, i.e. by adding
'x' elements for both XEP-0045 and MIX, and checking the response for
MUC/MIX flags to see which protocol the server uses).

7. §5.1.5 "Sending a Message". My biggest pain point with MUC is its
inability to associate a sent message with its reflected copy, to track
success of delivery. If an 'iq' is used in MIX, the 'iq' result needs to
contain the item ID or some other reference to the reflected item (BTW,
the 'iq' response example should also be added to the XEP). Still, it
would be nice to have a mechanism that does not rely on the 'iq'
response in case the client connection is terminated before the 'iq'
response arrives.  If messages are used OTOH, we still need some way to
associate outgoing messages to their reflections, and that method should
be a mandatory part of the XEP (the message-ID XEP maybe?).

8. Publisher element: The 'publisher' element on message items is not
quite clear. According to XEP-0060 this must be a JID, but I could see a
nickname here as well, though that would mean a higher overhead when
performing message attribution, as nickname changes need to be tracked
over time.

9. Stable User JIDs: In non-anon MIXes, the user's full JID can be used
for presence. For pseudonymous/anonymous MIXes, a mapping scheme is
needed that allows to group multi-client-users and for a user's client
to locate their other clients (i.e. for exchanging read-until-X
markers). That probably means that a dedicated domain is needed per-MIX
or per-MIX-service, where the user part is 1:1 mapped to the user's real
bare JID and MIX room, and the resource part is either the according
user's resource, or some 1:1 mapping of it (keyed hashing / encryption,
so no real resource is leaked).

For example:

a) hag66 at shakespeare.example/intibo24 joins coven at mix.shakespeare.lit,
   and is mapped to deadbeef at user.mix.shakespeare.lit/res0

b) hag66 at shakespeare.example/yaxim joins coven at mix.shakespeare.lit,
   and is mapped to deadbeef at user.mix.shakespeare.lit/res1

c) hag66 at shakespeare.example/intibo24 joins goodfolk at mix.shakespeare.lit,
   and is mapped to foobarbaz at user.mix.shakespeare.lit/res0

   (deadbeef, foobarbaz, res0 and res1 are arbitrary markers that should
   probably be replaced by UUIDs)

Have a fun time discussing and bringing forward the XEP,


Georg
-- 
|| 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: 811 bytes
Desc: Digital signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20160126/2a4dc4c7/attachment.sig>


More information about the Standards mailing list