[Standards] MIX Discussion topics for the Summit

Sam Whited sam at samwhited.com
Wed Jan 4 15:29:22 UTC 2017

I probably won't be at the summit, so here are some further opinions:

On Wed, Jan 4, 2017 at 3:33 AM, Steve Kille <steve.kille at isode.com> wrote:
> Q1.    Should MIX Channels and MUC Rooms be allowed to share a domain?
> 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 agree, I don't see the benefit in allowing them to be run on the
same domain; even if there is some benefit, I suspect that it's not
worth the added complexity. Let's keep it simple.

> Q2.   Should we retain MIX Subject?
> So, I would suggest that we drop Subject, unless a
> significant real use requirement is identified.  I do not think we should
> retain it simply for MUC backwards compatibility.

I also agree with this. If we need a concept of a subject for an
individual discussion within a room, this could be done later as a
separate thing (maybe tied into threading) that's unrelated to MIX
(and could be used in 1:1 chats); this seems more like something that
should be a building block that MIX, MUC, and 1:1 chats share.

> Q3.  Should we include Voice Control?
> I feel that this is a bit of complexity that MIX can do without.

Also agree; this could also be a separate XEP later (I think?) fairly
easily if necessary. For now I don't see a use.
However, I also think we should spend some time making sure we get the
permissions model for MIX right; if we were to simplify the
permissions model in MIX, voice might still be useful; I just don't
see its use in the current model.

> Q4.   Should we allow password controlled rooms?
> I am very strongly opposed to putting this into core MIX.

I agree again; instead maybe we could replace them with a
knock-to-enter scheme where moderators can approve individuals who
have requested to join the channel? I'm not sure this belongs in the
core spec, but I know the Jitsi team at least would want this if they
ever upgraded to MIX.

> Q5.  Should MIX Channels be added to the roster?
> I note that for operation where all clients have same MIX channel use,
> roster works nicely.

I've gone back and forth on this one a number of times; I like the
idea, but I'm worried that other clients and existing specs that deal
with the roster will have done things a certain way assuming that
everythihng in the roster was an individuals JID. I do think it's a
relatively elegant approach; I also don't think we should consider
(yet) the case where different clients want different channels. In my
opinion what channels you're joined too should be an account level
thing. If eg. a mobile client doesn't want to join an especially
chatty MUC, it can cache its own blacklist or whitelist locally (or we
can add more protocol later if it's an actual requirement, but it
would be a roster thing, not a MIX thihng).

> Q6. Where MIX Proxy is specified?

After many readings of the various MIX drafts, the concept of the MIX
proxy still confuses me. I think the entire idea might need a rethink;
fair or not, it just makes MIX *feel* bigger and more confusing; if we
tell people "to implement MIX you need to add client support, server
support, and run a third thing called a MIX proxy [even if that's not
really how it works, that's what it sounds like]" they're just not
going to implement MIX.

> Q8.  Should it be easy to obtain your own Proxy JID?

I also still think the concept of the proxy JID is confusing and
likely to make implementations harder. MIX has gotten too big and now
covers too many concepts. I propose that XEP-0383 or some other yet to
be defined, reusable spec be used for services that need to be


Sam Whited
pub 4096R/54083AE104EA7AD3

More information about the Standards mailing list