[Standards] Proposed XMPP Extension: Mediated Information eXchange (MIX)
kevin.smith at isode.com
Tue Jan 26 12:27:11 UTC 2016
On 26 Jan 2016, at 12:07, Georg Lukas <georg at op-co.de> wrote:
> 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.
I think this would be excessively hard for relatively little benefit (I could be wrong).
> 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
> 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.
> 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.
This is supported under MUC already with iq:register stuffs, so it’s not entirely new. You might be right that it doesn’t need to be in MIX.
> 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.
You can always fetch the current state from the pubsub node, which would contain all the current presences, which I think is what you need?
> 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).
Yes, I think this should be presence-based. There isn’t universal agreement, but I think we need it.
> 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.
We should be using JIDs as identifiers everywhere.
> 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,
Or it could be on the MIX domain itself, I think?
More information about the Standards