[Standards] UPDATED: XEP-0369 (Mediated Information eXchange (MIX))
georg at op-co.de
Fri Sep 2 09:59:40 UTC 2016
* Dave Cridland <dave at cridland.net> [2016-08-23 23:09]:
[MUC JID reference in a MIX]
> I think it's needed to allow a MIX client to communicate a MUC jid to
> another client.
Yes, unless the MUC JID is the primary (or the only) identifier of the
chat room, we need two-way references for interop, with the consequences
[MUC-JID as primary identifier]
> No, it means that the common currency, as it were, is the MUC jid, not the
> MIX jid, and MUC becomes baked in for interop for decades.
The alternative is a chaos where people see MUC JIDs and MIX JIDs
without understanding the difference, and inviting somebody to a chat
room becomes even more of a Russian roulette than it is already.
[MUC and MIX on the same JID]
> It's not wholly clear to me, yet, that a MUC interface onto MIX is going to
> be all that simple. I *am* certain that a MIX service needs to be written
> afresh, at least for Openfire, and a MUC interface to it needs to be
> written distinct from the existing MUC code.
My gut feeling is that if we don't want to break XMPP UX even more, we
will need to have MIX services with a MUC interface anyway. There are
multiple possible migration strategies for a server operator:
1. Kill all MUCs (alienates previous users), fire up MIX without
MUC-API (keeps alienating MUC client users). Easiest to implement,
2. Kill all MUCs (alienates previous users), fire up MIX with
MIX-MUC on the former MUC domain (old MUC users automatically land in
the freshly created compat zone; lose their history and ACLs; get
confused when invited to a MIX, but after asking the inviter for a
MUC JID, hearing a long explanation, upgrading their client, and
winning the Olympic Games, they will be able to participate again).
3. Keep legacy MUCs running, add a MIX domain and a MIX-MUC domain
(won't alienate legacy users, but invitations will be like in #2).
The sysop will have to be running the old MUC domain for whatever
time is required to phase out old users.
4. Convert legacy MUCs to MIX (either globally - as part of a server
upgrade, or when requested by the respective MUC owner). If both MIX
and MIX-MUC run on the same domain, this will be completely
transparent to users, and clients will be using the best protocol
they support. If different domains are used, a MUC-upgraded-to-MIX
will obtain an additional JID on a different domain (see #2 for
Obviously, the path of the least user alientaion goes via #4, with
transparent or MUC-owner triggered upgrading, and a shared domain for
both kinds of services. This also means the biggest implementation
burden for servers (though not for clients, as there is less JID
I'm viewing this from the IM perspective, and I don't think we as the
XMPP community can afford incompatible or confusion-causing changes in
one of our core features (group chats). Having separate MUC and MIX
namespaces with different, implementation- and operator-defined
incompatibilities would be highly confusing. I can see use cases where
all this doesn't play the least role (M2M communication, app+server silo
solutions), but my impression of MIX so far was that it is actually
targeted at the IM audience.
[Making MIX right]
> This too. I'd be very interested to write down what MUC interactions are
> needed, and how those map to MIX. Note that we probably don't need full MUC
> semantics everywhere.
Yeah, it would be really interesting to see the technical implications of
co-hosting MIX+MUC on the same domain, and of upgrading a chat room from
MUC to MIX.
[Stanza routing to MIX clients]
> We need PAM to be MIX-aware, basically.
The PAM spec is not advanced very far, especially regarding its
rationale. I can imagine this was discussed in-depth during the last
summits, but I wasn't there unfortunately. It would be great to have a
more explicit view of PAM, and how MIX is supposed to interact with PAM.
My inference so far is:
1. PAM handles PubSub routing from the user's account to their clients,
based on a client's caps or explicit session subscriptions or some
other mechanism (this is not clear from the spec).
2. MIX is using messages and presences instead of PubSub events, so PAM
needs to be aware of these and handle them accordingly.
3. You only can participate in a MIX if your local server is
[MIX JIDs in the roster]
> > Could you please outline the benefits as compared to e.g. bookmarks?
> > This needs special handling in the client anyway (i.e. the client needs
> > to remember / disco#info / caps-check) all roster JIDs anyway to see
> > which are users and which are MIXes.
> I'm not entirely sure it does. It'd be nice if it didn't.
A MIX is a different kind of entity than a contact, and it needs to be
handled differently at the protocol level. Furthermore, when the user
clicks a roster entry, the client needs to open the appropriate UI. For
this, the client needs to cache out-of-band the roster entry type, and
to query it from roster, PAM, caps or directly from the respective JID.
Now we have a situation where the client connects, obtains a roster and
must wait for all roster JIDs' type to resolve to contact or MIX, before
it is possible to open a chat window to them. If we store the contact
type on disk (and we need to do that to allow the user to write messages
when offline), there is a hypothetical possibility for a MIX domain to
become a regular XMPP domain, so that a MIX turns into a contact without
the client noticing (due to roster versioning optimizations).
And this isn't even considering the MIX-incapable clients for which a
MIX contact will look like a regular contact, totally breaking the UX.
Unless you want PAM to become a roster filter as well.
There is also a completely different (but roster related) thing that
recently came to my mind: what about MUC/MIX avatars? Wouldn't it be
awesome to have a "profile picture" associated with a group chat, that
could be displayed in the contact list, comparable to regular contacts?
Can we do that for MUCs? Will it be possible for MIXes?
|| 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...
Size: 811 bytes
Desc: Digital signature
More information about the Standards