[Standards] MIX clarity, MAM, and client-proxy interactions
georg at op-co.de
Thu Dec 22 12:08:44 UTC 2016
* Steve Kille <steve.kille at isode.com> [2016-12-22 12:32]:
> > All this is very complicated and demands clear language and a proper spec of
> > all the steps involved in an action.
> I think that the approach to address this is to identify specific
> points that are not clear and improve the text.
You are right of course. For me this is a bit of a chicken-egg problem.
Before I can provide specific points to improve understanding of the XEP
(which I hope I can find the time before the end of the year), I need to
understand the intent of the XEP.
> I think that 3.7 is correct.
> I do not think there is a need to attribute messages to specific
> clients. From a recipient perspective, messages come from other
I strongly disagree. Having a proper end-to-end message attribution to
clients is a requirement for many XMPP protocols, be it Chat State
Notifications, Message Acks, Last Message Correction or file transfers.
Once the basics are set, we could also use MIX-PM-to-ourself to
synchronize the read-state of individual MIXes.
IMO, providing client attribution is the main selling point for the
significantly increased complexity of MIX over MUC, and reverting that
won't do the protocol any good. Feel free to add this to the Brussels
> > You get a proxy-JID assigned on join, but you need to use an unrelated,
> > optional, feature to obtain it (and another two roundtrips).
> I don't see this as a big deal
Being a client developer, I do. If the proxy JID is to play any
significant role in MIX, it needs to be easy to obtain. And as we
exchange a <join> IQ anyway, we can add it there as a freebie.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 811 bytes
Desc: Digital signature
More information about the Standards