[Standards] MIX Discussion topics for the Summit
steve.kille at isode.com
Thu Jan 5 15:47:57 UTC 2017
Thanks for this. I will use this to update the questions list.
> * Steve Kille <steve.kille at isode.com> [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
> muc-a at chat.server.xmpp to coexist with mix-b at chat.server.xmpp - what
> I'm looking for is that a user can participate in mix-b at chat.server.xmpp using
> a MUC client by simply issuing a MUC join to mix-b at chat.server.xmpp.
> 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).
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-
> | 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.
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.
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.
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?
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
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?
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?
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,
And thanks for all the input
More information about the Standards