[Standards] Proposed XMPP Extension: Mediated Information eXchange (MIX)

Georg Lukas georg at op-co.de
Tue Jan 26 17:33:23 UTC 2016


* Kevin Smith <kevin.smith at isode.com> [2016-01-26 13:27]:
> Thanks Georg.
> 
> On 26 Jan 2016, at 12:07, Georg Lukas <georg at op-co.de> wrote:
[Share JID between MUC and MIX]
> I think this would be excessively hard for relatively little benefit (I could be wrong).

From the discussion in xsf@:
 - disco#items on a MUC will report back the participants, and on MIX
   the supported nodes.
 - A directed presence with no <x> element might be a MUC join by an old
   client, a MUC presence update that is parsed as a join due to
   "network wonkiness" or a MIX join.
 - The problems can be best discussed in-person.

Therefore I would kindly request the participants to thoroughly discuss
the pros and cons, and to provide a REALLY STRONG rationale if different
domain names are used. My gut feeling is that we can significantly
reduce the starting pains of MIC/MUX and reduce UX issues like extreme
user confusion by using the same domain name for both protocols.

Immediate benefits that come to my mind:
 - No separate vhost configurations on MIX+MUC servers required
 - Automatic protocol handshake between client and server
 - Much easier invite handling between MIX and MUC clients
 - (If properly implemented) a user can participate with a MUC and a MIX
   client in the same chatroom

> > 4. §5.1.2 "Registering with a MIX Service" [...]
> 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.

iq:register works on individual rooms, not on a service. Therefore, it
provides a functionality very comparable to a MIX join. §5.1.2
introduces service-wide registrations that I would consider irrelevant.

> > 5. §5.1.3 "Coming Online" and Presence Reflection / MAM: [...]
> 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?

I'm not an expert on PubSub (actually very far from it), so I don't
quite get how it is handled internally in the pubsub node, and how the
protocol looks like. Does the MIX service keep a special current-state
item that contains all the "online" participant presences? I'd like to
see examples for that in the XEP, and feel free to flame me off-list
with the gory details.

> > 9. Stable User JIDs: [...]
> Or it could be on the MIX domain itself, I think?

I'm not opposed to that, but I'd rather have the MIX domain be shared
with MUC, and not with pseudonymous MIX participants. If we use the MIX
domain, we need to ensure that there are no name conflicts between rooms
and users, and furthermore that Service Discovery requests are properly
forwarded to the users.


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 ||_________________________________________________||
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 811 bytes
Desc: Digital signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20160126/d1437f2e/attachment.sig>


More information about the Standards mailing list