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 <[email protected]> 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 anonymous. —Sam -- Sam Whited pub 4096R/54083AE104EA7AD3 _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
