[Standards] MIX clarity, MAM, and client-proxy interactions
georg at op-co.de
Thu Dec 22 10:26:33 UTC 2016
let's agree to disagree on the design decisions. I think this really
needs to be tackled in Brussels, where we have a larger number of
experienced protocol designers. It would just be important to discuss
the trade-offs imposed by the alternatives, and to write down the design
decisions and their rationale into the XEP.
I'd still like to use this thread to better understand the current
design and to resolve the remaining questions I have.
* Steve Kille <steve.kille at isode.com> [2016-12-22 09:47]:
> Note that for a MIX client, the local MAM archive is used. This is
> the one on the same server as the MIX Proxy.
Wow, I absolutely missed that update. Now, on rereading §5.4 it makes
sense to me, and I see how this can be solved by the new MAM-binding. We
might need to hook MIX activation into the new binding mechanism, but it
all looks solvable to me now.
> > I can't see how having the client's bare JID reflected in an IQ respsone makes
> > any sense.
> [Steve Kille]
> This will cause it to be directed to MIX proxy, rather than the client.
This points out a fundamental problem I have with understanding the XEP.
There are at least four types of interactions:
* client <-> MIX service/channel - service/channel discovery, sometimes MAM
* client <-> proxy - activation, regular MAM, message/presence delivery?
* proxy <-> channel - message/presence delivery
* client <-> other participant's client - IQs and PMs
There are also chained interactions, where the client sends something to
the proxy (e.g. to initiate a join), and the proxy sends something else
to the MIX channel (e.g. Example 28). And maybe also interactions where
the client sends something to a channel, but its proxy performs local
actions or manipulates the packets transparently (like filtering
undirected presence transmission to non-activated MIX channels).
All this is very complicated and demands clear language and a proper
spec of all the steps involved in an action. However, the XEP does not
specify many of the client interactions, and in many cases doesn't
explicitly state which parties are interacting in a given example.
The XEP further states in §3.4 that "The behaviour of a MIX Proxy and
the protocol between MIX Proxy and MIX Client is not currently defined
in this specification. It will be defined in one of three places." --
I'm not sure if this is a leftover from an older revision or if we
really are designing only one half of the protocol.
You already noticed my confusion and misunderstanding, and I think it is
based to a large part on not understanding from the text and examples
which parties are involved in a given place.
I'll gladly re-read and provide a list of places that should be made
more explicit, but for that I need to know if the XEP is also supposed
to define the client<->proxy interaction protocol.
> > The client needs to know their own proxy JID because it is the sender JID of
> > reflected messages.
> Ah! The 0.6.2 does have messages sent out with proxy JID. I
> believe that this is a mistake, which I have now corrected.
This is another incarnation of my understanding problem. Before your
last change, Example 45 was showing a full-proxy-JID to bare-real-JID
groupchat message which was sent from the MIX channel to the MIX proxy.
That allowed the MIX proxy (and the user's client) to attribute the
actual message to a given client of the sender. The new format is
essentially a MUC message from the MUC-JID-with-sender-nick-as-resource,
a format that we wanted to get rid of because it does not allow the
addressing of (and message attribution to) a given client. It also
contradicts §3.7, "The primary representation of a participant in a MIX
channel is a proxy JID".
> It is also not easy to find their own proxy JID based on
> > the NICK because the NICK is optional.
> If a client sends messages, nick is mandatory.
This is a very unfortunate protocol design:
You get a proxy-JID assigned on join, but you need to use an unrelated,
optional, feature to obtain it (and another two roundtrips).
[Proxy JID in <join> response]
> Disagree. We can review in Brussels.
Please do so.
I also just realized that we have a wording conflict here: a "MIX proxy"
is a module running on your server, and the "proxy JID" is a virtual
address that is associated to users/clients in a given MIX channel.
These two proxies don't have anything in common, and it would be great
to rename one of them to better separate the concerns.
My suggestion would be to rename "MIX proxy" into "MIX agent", which is
a well-matching term from the Mobile Computing domain for a small remote
application that performs actions on behalf of a user.
Thanks very much for your tireless work,
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 811 bytes
Desc: Digital signature
More information about the Standards