[Standards] MIX Discussion topics for the Summit

Georg Lukas georg at op-co.de
Thu Jan 5 09:36:15 UTC 2017


please find inlined my talking points and questions for the summit,
which I'm not able to attend in person:

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

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.

> Q2.   Should we retain MIX Subject?

GL: +1 for dropping the Subject.
Conversations and ChatSecure already are abusing the subject as a room
name in ad-hoc MUC.

> Q4.   Should we allow password controlled rooms?

GL: No, but we can replace it with a mechanism to add people without
knowing their JIDs. PARS (XEP-0379) comes to mind and is probably easily

> Q5.  Should MIX Channels be added to the roster?

GL: IMHO, the benefits don't outweigh the compatibility issues. If we
decide for explicit MIX activation, e.g. as part of a new
MAM-carbon-session-binding, there is no more technical need for having
MIXes in the roster and to break non-MIX clients.

And in my eyes, explicit MIX activation is needed both for mobile
clients to select a subset of channels, and for regular clients to be
able to specify how much MAM history they want to fetch [per room].

> Q7. Should we change the name "MIX Proxy"?

GL: My suggestion of "MIX Agent" has two reasons: "proxy" has a totally
different meaning in "proxy JID" in the same XEP; and "agent" is the
correct term for what the user's server is supposed to do here. You can
call it "PAM" or "MIX account" or anything else, as long as it adequately
describes the task it has to accomplish and doesn't conflict with other

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

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

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?

Q11. Can we design MIX in a way that users can mix MIX-clients and
non-MIX legacy clients? Related to: Q1+Q5+Q10

Q12. What happens when a user with a MIX-capable client tries to join a
MIX using a non-MIX server?

Q10. What mechanism are we going to use to allow multi-clients to sync
the read-state of a channel?

> 1.   MAM Updates.  There are some changes under discussion in MAM which will
> quite likely lead to MAM IDs being included in payload.   If these have
> happened, we need to discuss in context of MIX.

GL: +1 for adding MAM-IDs to all messages.

I wish you a nice and productive time in Brussels,

|| http://op-co.de ++  GCS d--(++) s: a C+++ UL+++ !P L+++ !E W+++ N  ++
|| gpg: 0x962FD2DE ||  o? K- w---() O M V? PS+ PE-- Y++ PGP+ t+ 5 R+  ||
|| Ge0rG: euIRCnet ||  X(+++) tv+ b+(++) DI+++ D- G e++++ h- r++ y?   ||
++ IRCnet OFTC OPN ||_________________________________________________||
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 811 bytes
Desc: Digital signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20170105/0014cb06/attachment-0001.sig>

More information about the Standards mailing list