Georg, Thanks for this. I will use this to update the questions list.
> * Steve Kille <[email protected]> [2017-01-04 10:36]: > > Q1. Should MIX Channels and MUC Rooms be allowed to share a domain? > > GL: This is actually the wrong question to ask. I don't think anybody wants > [email protected] to coexist with [email protected] - what > I'm looking for is that a user can participate in [email protected] using > a MUC client by simply issuing a MUC join to [email protected]. > > This would require a MIX service to proive a Minimal Viable Protocol > implementation of the MUC protocol (and of course for the MIX service and > MIX proxy not to break non-MIX clients). [Steve Kille] I think the original question is a good one and needs to stay. I will add a new question to reflect this point. > > To quote myself, as of https://mail.jabber.org/pipermail/standards/2016- > August/031315.html > > | I think this is imperative for easy coexistence and upgradeability > | from the current MUC infrastructure to using MIX. We should explicitly > | support accessing the same chatroom via both protocols under the same > | JID: This will make the UX much smoother and spare us the pains and > | debugging problems of a hidden actual service JID that needs to be > | communicated between MUC-vs-MIX clients. I would even ask for allowing > | a user to use a MIX and a MUC client at the same time, sharing a nickname. > > As I wrote in that mail, the only clash between the protocols I see so far is > disco#items, and we could use a different query namespace to obtain the list > of MIX nodes on a given room JID. [Steve Kille] FWIW, I think that doing this is a very bad idea > > > Q8. Should it be easy to obtain your own Proxy JID? > > GL: I'm with Sam here. The whole concept makes MIX horribly complicated, > and I'd love to see proxy JIDs burned with fire. The next-best option would > be to serve the client its proxy JID on a silver plate, during join. There > really is > no reason NOT to give the client its proxy JID, and it will be needed anyway, > e.g. to mark your own entry in the MIX participant list. [Steve Kille] I've added a question here so that the group can re-affirm or reject proxy JIDs. I explained in earlier response why you do not need a proxy JID for this purpose. > > > Q9. Usage of full vs. bare JIDs for MIX messages sent between MIX proxy > and MIX channel, and between MIX client and MIX proxy. I'm not sure if this > story is fully developed yet, and it probably needs to be sketched out. [Steve Kille] I don't think there is a question here. There may well be editorial details to sort out, but the model and core is clear. > > > Q10. What is the interop story with Carbons? Is the MIX proxy responsible for > delivering MIX messages and PMs to all MIX-joined clients, or will one client > receive the master copy and the others will get Carbons? [Steve Kille] No story. Carbons are for 1:1. MIX sorts out multi-client and does not use carbons. > > > Q11. Can we design MIX in a way that users can mix MIX-clients and non-MIX > legacy clients? Related to: Q1+Q5+Q10 [Steve Kille] This is covered in the new Q2. Trying to do this is a very bad idea. > > > Q12. What happens when a user with a MIX-capable client tries to join a MIX > using a non-MIX server? [Steve Kille] It is violating the spec, so should not do this! > > > Q10. What mechanism are we going to use to allow multi-clients to sync the > read-state of a channel? [Steve Kille] I think the spec is clear on this. I don't think there is MIX design choice question for the group here. > I wish you a nice and productive time in Brussels, [Steve Kille] Thanks! And thanks for all the input > > > Georg [Steve Kille] Steve _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
