[Standards] MIX Discussion topics for the Summit

Steve Kille steve.kille at isode.com
Thu Jan 5 15:47:57 UTC 2017


Georg,

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).
[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





More information about the Standards mailing list