Hello again, * Dave Cridland <[email protected]> [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. [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 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 PAM-enabled. [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? 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 ||_________________________________________________||
signature.asc
Description: Digital signature
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
