[Standards] MIX and MUC sharing a domain

Dave Cridland dave at cridland.net
Wed Jan 4 16:38:58 UTC 2017


On 4 January 2017 at 16:02, Steve Kille <steve.kille at isode.com> wrote:
> Dave,
>
>
>
> 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.
>

OK - my concern (and I think Georg's concern too) is that a MIX client
can locate the MIX channel from the MUC interface, but a non-MIX
client cannot locate the MUC from the MIX interface, since it will
never understand that - meaning that the "address of record" for the
chatroom will be that of the MUC service, and not the MIX.

That means that retiring the MUC service is going to be very hard, if
not impossible. This seems highly undesirable.

I have no interest whatsoever in having a *full* MUC service
operational on the same domain as the MIX service. But I would like to
explore a legacy MUC-compatibility service so we can avoid having
whole legacy domains hanging around forever.

This is, as you say, something we can discuss further in Brussels - I
just don't want it to be considered a lost cause from the outset.

>
>
> We can discuss further in Brussels
>
>
>
>
>
> Steve
>
>
>
>
>
>
>
> 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).
>
>
>
>
>
>
> _______________________________________________
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe at xmpp.org
> _______________________________________________
>


More information about the Standards mailing list