[Standards] MIX and MUC sharing a domain

Steve Kille steve.kille at isode.com
Wed Jan 4 16:02:15 UTC 2017



Making the details of sharing a domain work will be hard.


A key point is that MIX defines a way for MUC and MIX domains to cross reference each other.   This means that a MIX capable client will move transparently from a MUC room to the equivalent MIX channel.      This is all going to be very neat and transparent, and does not need the domain to be shared.


We can discuss further in Brussels







From: Standards [mailto:standards-bounces at xmpp.org] On Behalf Of Dave Cridland
Sent: 04 January 2017 15:43
To: XMPP Standards
Subject: Re: [Standards] MIX Discussion topics for the Summit



Q1.    Should MIX Channels and MUC Rooms be allowed to share a domain?

SEK:   The spec currently allows this, and some issues around this have been
identified (by Georg Lukas).   I think that trying to make this work will
cause much pain and so we should explicitly require the MUC and MIX do not
share domains.


I think we should try to do this. If we do not, then (for example) xsf at muc.xmpp.org will end up being MUC-only, and we'll have to have a new address for the MIX equivalent. Worse, this will more or less always be the case until MUC disappears entirely, which will take years.


It feels fundamentally counter to any attempts to build a reasonable end-user UX to have addressing split on protocol rather than function.


An option to resolve this is to spent some time at the Summit (or before) on defining a known-safe subset of MUC which is known to (or at least thought strongly to) be supported by existing clients in normal operation, and suggest that MIX services implement that. This might, for example, provide only very limited information, no disco, and so on - but would give a degraded, but functional, interface for legacy clients (ie, every client currently in existence).



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20170104/c3ee9b29/attachment-0001.html>

More information about the Standards mailing list