Georg,
> -----Original Message-----
> From: Standards [mailto:[email protected]] On Behalf Of Georg
> Lukas
> Sent: 21 December 2016 13:26
> To: [email protected]
> Subject: Re: [Standards] MIX Status (0.6.1), review, and Brussels Summit
>
> Hi Steve,
>
> thanks for the reivew of the review, I'd like to add some more reasoning to
> some of my arguments below.
>
> * Steve Kille <[email protected]> [2016-12-21 11:50]:
> > You are right that a high bar has been set. [...]
> >
> > Operationally, I believe that this will be mitigated by server
> > implementations that support both MIX and MUC, and following the
> > procedures of section 7. This will enable transitional operation.
>
> I agree, but this will only work out under two conditions:
>
> 1. we design MIX in a way that does _not_ completely break the usage of
> MUC-only clients (this is also why I dislike the MIX-in-roster
> approach).
>
> 2. we make it possible to run MIX and MUC-compat on the same domain
> (everything else will force us to use the MUC JIDs as the primary
> identifiers for chatrooms forever).
>
> I don't see major roadblocks for either condition, so I'm also slightly
> optimistic regarding the future of MIX.
[Steve Kille]
I don't agree with these conditions. In my view the key goal for MIX is to
provide modern multi-user communications.
>
> > > We might need to codify how a MIX-enabled client connected to a
> > > non-MIX server should behave (MUC fallback?).
> > [Steve Kille]
> >
> > I don't think this is needed. A client can implement both MIX and
> > MUC. The standards do not need to proscribe how this interacts in
> > user experience.
>
> While I tend to disagree on your last point, this is a topic for a different
> discussion.
>
> Either way, we SHOULD define how the client implementation should behave
> protocol-wise, when a MIX-enabled client is connected to a server without
> MIX-proxy support, and the user wants to enter a MIX.
[Steve Kille]
Disagree. This is a combination that is not supported.
>
> > > ## Race Condition During Sync
> > There is an issue here. Kevin Smith and Matthew Wild are discussing
> > an approach to modify client bind in order to address this.
>
> The client-bind modification is eagerly awaited. However it won't solve the
> problem for MIX-MAM, unless we change the MIX spec to store the MAM
> archive in the MIX proxy instead of the MIX service.
[Steve Kille]
Note that for a MIX client, the local MAM archive is used. This is the one on
the same server as the MIX Proxy.
>
> > I do not think there is any specific MIX issue, although I believe
> > that MIX will be dependent on this new specification.
>
> As long as we query the MIX service for our MAM, we need to create a new
> atomic operation for query+subscribe to avoid race conditions. In the current
> design, all messages get forwarded to the MIX proxy anyway, so the
> operation needs to be atomic only between client and MIX proxy, making it
> less of a problem.
>
> One possible solution would be to extend the activation IQ with a MAM sync
> anchor, another (as stated above) to store the MAM archive on the user's
> proxy. There are probably more options, e.g. to ignore the race condition
> and let client developers do the dirty work of history merging.
>
> My point is just that the current design is unclean in this regard, and we are
> aiming at creating the best possible protocol.
[Steve Kille]
I don't think there is a problem. I propose we defer this discussion until
the new BIND spec is available for general review, and we can consider MIX in
context of this.
>
>
> > > I'm still not convinced it is a good idea to add MIXes to the roster.
> > I strongly view that having MIX channels in the roster is a good
> > thing. It allows presence to work for MIX using standard XMPP
> > mechanisms.
>
> Except that the MIX proxy needs to ('SHOULD') intercept presence anyway
> and to only forward client presence to MIXes that the client has activated.
[Steve Kille]
I believe that this is what the MIX specification says. If there is wording
that contradicts this, please point it out and I will fix it.
>
> It is really bad to have different specifications for presence routing (based
> on
> roster subscription and a 'SHOULD') and message routing (based on client
> activation).
>
> We should promote the MIX client activation to a first-class citizen of the
> XEP,
> and use its rules both for message and presence routing.
[Steve Kille]
MIX client activation IS a first class citizen of the XEP. What suggests that
it might not be?
>
> If we add MAM synchronization to the activation, we also elegantly solve the
> race condition.
>
> And if we decouple MIXes from the roster and instead maintain a joined-MIX
> list in the MIX proxy, we win multiple things:
>
> * no need to extend the roster format
> * no need to query each contact whether they are a MIX
> * we restore the user's ability to use pre-MIX clients on the same account
>
> I think the main benefit of MIX-in-roster is to be able to add MIXes to roster
> groups (and to rename them, though I'm not sure this is a good thing, as it
> introduces interesting UX conflicts).
>
> I'm not sure if this is really a demanded feature, and if we can't solve it
> with
> less overall headaches.
[Steve Kille]
I think that you are trying to solve a problem that does not exist.
>
> > > Furthermore, the roster does not provide a way to distinguish MIXes
> > > from regular contacts, unless the roster format is also extended.
> > [Steve Kille]
> >
> > I think that for most clients/users this will not matter. It will be
> > easy for me to distinguish MIX channels, and I would likely group in
> > the roster.
>
> It probably doesn't matter for the UX side, but it does for the implementation
> side. If you put all MIXes into a separate roter group anyway, there is no
> compelling reason to have them in the roster in the first place.
[Steve Kille]
I simply noted this as to how I might handle this. Putting MIX channels into
the roster enables us to leverage a stack of existing XMPP functionality.
MIX is going for re-use of core XMPP capability wherever possible.
>
> > The client can easily work out if a roster member is a MIX channel and
> > can "do clever things" if it wishes.
>
> In the worst case, this requires a round-trip to the MIX, so the client must
> defer important UI decisions (which icon to use, which context menu to
> provide) until it receives the response from the respective contact.
>
> From a client developer's perspective, this is a little nightmare that should
> be
> avoided if any possible.
[Steve Kille]
Sorry - I really do not see an issue here.
>
> > > A client needs a way to obtain the list of all joined MIXes (e.g.
> > > from the MIX proxy), so it can decide which MIXes to activate.
> > [Steve Kille]
> >
> > I had pictured that many clients will take a simple approach of just
> > activating all MIX channels.
>
> That's simple, unless you also want to synchronize the MAM archive from
> the respective MIXes.
[Steve Kille]
This is just basic MAM use. I do not see a problem.
>
> > Another approach would be to tie to bookmarks, so that essentially you
> > activate a MIX channel on startup if bookmarked.
>
> I don't even want to get started about bookmarks, as currently deployed and
> used for MUCs... If we want them to be used for MIX, we need to fix them
> first.
[Steve Kille]
If work is needed to improve bookmarks, lets do the work needed to improve
bookmarks. This should be a sound XMPP component that MIX can utilize.
>
> > A client can find a list of MIX channels in which the user is
> > participating from the roster. A MIX proxy command to list channels
> > might be helpful in the future.
>
> I would do it the other way 'round. Have the MIX proxy hold a list of joined
> MIXes (it has to anyway) and expose that via an IQ.
[Steve Kille]
Yes - that seems a sensible way to achieve this. I still view that we should
not add this now. I noted this as a possible future option, but it is unclear
to me if it will be useful in addition to what can be achieved without it.
>
> > > Once the client sends activation, the MIX proxy could forward the
> > > client's presence to the MIXes, so we don't need to put them onto
> > > the roster for this either.
> > This is a possible alternate approach. It puts some quite low level
> > requirements onto the MIX Proxy and it feels to me preferable to use
> > the roster and RFC 6121.
>
> The MIX proxy is already in a situation where it needs to filter messages and
> presence.
>
> > I'm happy to put this onto the agenda for Brussels.
>
> That would be great. Unfortunately, I won't be able to attend, but I hope that
> the assembled community will find a nice and elegant solution to all the open
> points.
[Steve Kille]
I'll make sure that we get to discuss this and the other points you raised.
>
> > > [§5.1.8 client presence synchronization]
> > I realised on review that the role of MIX proxy has not been written
> > up. In most cases the MIX Proxy will hold current presence
> > information and so when a client comes online, it can get this
> > information from the MIX Proxy. I have added text to cover this.
>
> Thanks, I've had a peek into the PR and I like the new wording.
>
> We only need to keep in mind that the MIX Proxy sometimes needs to be
> fully synchronized with the MIX channel as well.
[Steve Kille]
OK - let me have any specific changes you would like.
>
> > > ## Internal Consistency
> > >
> > > The standard nodes in §3.7 have very different usage semantics.
> > > [...]
> > This inconsistency has arisen for a number of good reasons, or more
> > accurately because of the consequences and interaction of the good
> > reasons.
>
> I think it would be great to have another column in Table 3, that lists the
> access method, i.e.:
>
> Messages | | |Message Stanzas
> Participants| | |PubSub
> JID Map | | |PubSub
> Presence | | |Presence Stanzas
> ...
[Steve Kille]
That's a neat idea. I've added this.
>
> > Detailed suggestions on sections to clarify are welcome.
>
> I'll have another read of the XEP when it's published, and will try to create
> a
> wording-related PR.
>
> > > ## MUC Interop
> > I am not convinced that implementing MUC and MIX on the same domain is
> > viable. It is certainly not going to be easy. Your note points out
> > an issue.
>
> Just to clarify: I'm not speaking of a full MUC implementation running on the
> same domain as a MIX implementation, but of a MUC interop layer to access
> the MIX service, to allow MUC-only clients to participate in MIXes. It could
> be
> implemented in the MIX proxy or in the MIX service, and it does not need to
> implement the full MUC protocol.
[Steve Kille]
I think that client and server implementers will be looking to provide a
sensible solution to support both MUC and MIX. I think that the current
specification allows this.
>
> > My recommendation would be to not allow this and to require MIX and
> > MUC domains to be distinct. I suggest that we discuss in Brussels.
>
> I can understand that it makes the server/service implementation more
> complicated, but it will significantly improve the MUC-to-MIX migration UX.
> The compatibility/UX issues I outlined in September
> <https://mail.jabber.org/pipermail/standards/2016-
> September/031364.html>
> are still valid, as far as I can see.
>
> I think you need to bring up the topic in Brussels, and the first decision
> that
> needs to be made is which UX we want to create, not which technical
> implementation is easiest to do or even most elegant.
>
> The UX of XMPP is so bad that we are bashed by the IT crowd whenever
> anything messaging-related comes up. We can make the best and nicest MIX
> XEP, and it won't be used by anyone if we don't focus on the UX first.
>
> Therefore my favorite is still #4 from the referenced email, where MIXes can
> be accessed using the MUC protocol on the MIX domain from a MUC-only
> client.
[Steve Kille]
I think that UX belongs to products not to standards.
The goal of standards is to provide flexible interop in a way that allows
implementers to build products with excellent UX
I think that you are overly focussed on MIX/MUC co-existence. I think the top
priority is for MIX to be good.
>
> > > ## Joining a MIX
> > I think that in 24, it is desirable to use a JID that matches the real jid,
> > as part
> of the client confirmation.
>
> 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.
>
> > In practice, there is little reason for a client to need to know their
> > own proxy JID. So I don't see a need to extend the protocol. A
> > client can easily find proxy JID by matching their own NICK in the
> > participants list.
>
> The client needs to know their own proxy JID because it is the sender JID of
> reflected messages.
[Steve Kille]
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.
It is also not easy to find their own proxy JID based on
> the NICK because the NICK is optional.
[Steve Kille]
If a client sends messages, nick is mandatory.
>
> If we have a JID field in the <join> stanza, we should use it for the proxy
> JID
> (and rename it appropriately). That spares us another roundtrip, doesn't
> force clients to subscribe to the participant node and makes message
> matching easier.
[Steve Kille]
Disagree. We can review in Brussels.
>
> > > ## Converting a 1:1 Chat
> > Ah yes, there are some issues here. I have updated. Let me know
> > what you think of the new text.
>
> I've started a separate discussion about the general UX and security
> implication of the conversion.
[Steve Kille]
OK. If there are specific changes to MIX, please make sure they get brought
out for my attention.
>
> Regarding message history, it might be good to re-use XEP-0297: Stanza
> Forwarding, instead of creating a new <resend> element.
[Steve Kille]
I was not aware of 297. Using 297 here is sensible. I have updated the XEP.
>
>
>
> Georg
[Steve Kille]
I have made the three changes noted and issued a PR for version 0.6.3
I really appreciate all your comments and input. I will use this thread to
help build a list of topics for Brussels. It has brought out a number of
points we do not agree on, and it is important to get wider input.
I suggest that we draw this thread to a close now, and that you provide any
further comments in a new message or messages.
Best Regards
Steve
_______________________________________________
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: [email protected]
_______________________________________________
