[Standards] UPDATED: XEP-0369 (Mediated Information eXchange (MIX))
dave at cridland.net
Fri Sep 2 10:32:45 UTC 2016
On 2 September 2016 at 10:59, Georg Lukas <georg at op-co.de> wrote:
> Hello again,
> * 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
> outlined below.
> [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.
Yes, I think we're in agreement - there's a horrible mire of UX
nastiness that'll occur if we end up with multiple parallel systems in
play that won't work together.
> [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,
> maximum embarrassment.
> 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
> invitations issues).
> 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
> juggling involved).
I'm not sure - yet - how much we can do here in practical terms to
ensure we get as close to (4) as we'd like, but I'd hope so. I agree
that in order to get transition in any pleasant way, we need to get as
close to (4) as possible.
I'm reasonably confident, though, in suggesting that in the Openfire
case at least, there'll likely be three conferencing protocols
2) Legacy MUC - existing full XEP-0045 interface, with all the
features (Openfire's implementation includes pretty well every
optional part of the spec, even including nick-sharing these days).
3) MUC<->MIX Gateway - a partial, probably not fully conformant, '45
interface onto MIX. Lots of things won't work (probably no
moderator/admin/owner use cases, for example, and disco will behave
like MIX rather than MUC).
The question is really how high the fidelity on that third protocol to
'45 needs to be in pragmatic terms to support existing clients for
> 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).
I had notes on a solution here, *and* a solid idea we'd discussed this
and got a solution, but it makes no sense in the cold light of day.
> 2. MIX is using messages and presences instead of PubSub events, so PAM
> needs to be aware of these and handle them accordingly.
Yes, that would be the idea.
> 3. You only can participate in a MIX if your local server is
That's not so clear to me. It feels like a bad idea to totally rely on
PAM being prevalent before MIX is deployed, although I think such a
thing would make multi-device use-cases work much better.
> [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).
You're probably right.
However, I like the notion that a MIX channel could subscribe to a
user's presence, instead of clients having to first locate the joined
channels via PAM (or bookmarks) and explicitly send presence to them.
Perhaps we should both place them into the roster and then enhance the
roster to fit? Would solve the below as well, possibly.
> 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?
No, and we should fix this. Actually a profile picture would very
easily just be another pubsub node, I think.
This is also the perfect example of why a client issuing a MIX Join
listing non-existent nodes will benefit from the channel
auto-subscribing the client to those nodes at a later date when the
> || 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 ||_________________________________________________||
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe at xmpp.org
More information about the Standards