Hi, * XMPP Extensions Editor <[email protected]> [2016-08-16 12:33]: > Version 0.2 of XEP-0369 (Mediated Information eXchange (MIX)) has been > released.
Thanks to everybody involved! Let's get this one moving fast, now! :) I like the overall design, but I think some aspects of it can be improved. 1. Sharing a domain between MUC and MIX ======================================= I think this is imperative for easy coexistence and upgradeability from the current MUC infrastructure to using MIX. We should explicitly support accessing the same chatroom via both protocols under the same JID: This will make the UX much smoother and spare us the pains and debugging problems of a hidden actual service JID that needs to be communicated between MUC-vs-MIX clients. I would even ask for allowing a user to use a MIX and a MUC client at the same time, sharing a nickname. From the protocol side, the only clash I can see is disco#items on a room JID, which returns the participant list for MUC, and the supported nodes for MIX. I'm not sure if there is an elegant way to discriminate these use cases with the query (Have a separate well-known query JID for MIX nodes? Add a custom element to the iq-get? Have some namespace for the query? Return both MUC participants and pubsub nodes?), but I would be ready to settle with a less elegant solution for the sake of better UX and interop. 2. Use of client's bare JID =========================== Sending of presence and message packets to the user's bare JID is going to break things. First, message routing is server-defined, and will cause different behavior on different servers. Second, a client with a negative presence priority will not be able to receive data from MIX. Third, messages and presence stanzas will end up routed to clients that do not support MIX or do not know which channels the user is on, causing weird UX issues. Fourth, client authors will have to implement and enable carbons, and handle carbonated MIX messages like regular MIX messages (whereas carbonated private messages might have slightly different semantics). Fifth, these messages will end up in the user's offline storage, probably confusing a later resync. As not all clients are going to implement MIX overnight, the protocol should not force new types of messages onto legacy clients. Therefore I propose to make MIX participation more explicit: a) always use the client's full JID to send MIX related stanzas b) require a MIX capable client to explicitly send directed presence to all MIX rooms it is interested in (§5.1.6 is okay in this regard, though I'd like to see an explicit extension element akin to MUC-join; a dumb client could just put both MUC and MIX extensions into a presence packet and see what comes back ;-)). c) As a consequence, MIX JIDs should not be part of the user's roster. I don't particularly like the alternative (bookmarks), but it still sounds better to me than breaking legacy clients. d) As another consequence, the MIX service would send copies of a MIX message/presence to each client of each user, instead of only once per user. However, this will avoid the mess that RFC6120 message routing + Carbons is. 3. Message tracking =================== Initially, MIX messages were going to be handled like pubsub events. The text in §5.1.11 still claims so (I suppose this is an overlooked remnant). Example 30 shows a regular message with a rewritten 'id'. I'm still strongly in favor of having a stable way for a client to identify a reflection of an outgoing message, as discussed in [0]. If we use MAM, reflected messages should be identified by their MAM archive id, allowing for a later follow-up sync. However, client- originated messages are not identifiable with this approach, and it would be great to have the original packet ID reflected, or at least an additional element with the original packet ID, so that the client can mark the message as "delivered". 4. Capability Reduction ======================= I'm not quite sure why MIX allows to register a service-wide nickname, but passwords and voice control got kicked. Personally, I would also kick the nickname registration feature: IMHO it doesn't make very much sense in a federated environment where most chat rooms are distributed over different service domains anyway, and where the real JID is the only reliable identifier anyway. While we are at it, I don't like the idea of proxy JIDs very much either, and I'd rather have gone with the MUC-light proposal of just using users' real JIDs everywhere. It would make the implementations much easier and less error-prone... And we are living in a post-privacy world anyway... Georg [0] https://mail.jabber.org/pipermail/standards/2014-July/028988.html
signature.asc
Description: Digital signature
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
