[Standards] XEP-0369 (MIX): Early stages of a clients connection
jonas at wielicki.name
Wed Jun 14 06:17:22 UTC 2017
On Dienstag, 13. Juni 2017 17:08:00 CEST Steve Kille wrote:
> I've just made changes for MIX 0.9.3, in which I have attempted to address
> the three issues raised here. The approaches are simple and have not
> added a lot of text.
> The server receiving the message will then deliver the messages to all
> online clients with status available and a non-negative resource priority.
I think the new wording here excludes any client with e.g. away, na, dnd or xa
status from receiving MIX messages. That sounds like overkill (I’m not even
sold on not receiving MIX messages with negative presence priority actually).
> When a client adds MIX capability, additional information needs to be
> provided by the server. To support this, a server MUST maintain
> information about client MIX support status. When a server detects this
> change it needs to update the roster which it MAY do incrementally or by
> sending all of the roster.
Could you elaborate how that works in the following scenario: Alice uses the
client A, version 2.0 on her desktop and client B, version 1.0 on her phone. B
1.0 does not support MIX, but A 2.0 does. She is connected with both clients
in parallel. She chats with both, but uses MIX only on her desktop with A 2.0.
She has some MIXes bookmarked. Then she updates B on her phone to version 2.0,
which finally supports MIX. Since B is mobile oriented, it uses roster
versioning and asks the server for an incremental roster update when
How exactly does the know that B did not support MIX on the last connection,
but does now? I.e. how does the server recognise the "same" client on
One thing I could imagine is for the server to include that information in the
roster version. E.g. if it usually versions the roster with incrementing
numbers, it could add "+mix" to the stringified number if MIX entries are
included. This would allow it to recognise that the client has or has not seen
a roster version with MIX and can create the diff accordingly.
It took me a while to come up with this idea, so maybe it makes sense to add
that to the wording. Also I have never written a server-side roster
implementation, so I’m not sure if this is even a realistic way of doing
I‘m still not happy with the extra round-trip required by the server for
discovering the feature before responding with the roster, but from discussion
in xsf@ (if I recall correctly, mainly with Dave), this may be a general
problem we’d like to solve in a different protocol (like gratuitous entity
capabilities sent by clients to the server before presence or something
> I have not pushed as a PR because of namespace numbering. It seems
> likely that if a change is pushed every time we make a protocol tweak,
> there is going to be a serious problem of namespace number proliferation.
> I think the options are:
> 1. Keep changes on a working branch and defer pushing. This gives less
> visibility of work in progress.
> 2. Push and increment namespace. Problem noted above.
> 3. Push the PR and leave version number on mix:0. I think this may be
> the pragmatic solution, provided it does not cause a problem for those
This is a general question. In software library development, one would have a
major update (here: things which require a namespace bump) branch and a minor
update (here: things which do not require a namespace bump) branch, with the
minor changes continuously flowing in the currently supported release.
However, the XEP process does not make it easy to have these two branches
exist in parallel in a manner which allows easy viewing and discussing.
In this particular case, I’d suggest seeking consensus`from those who work on
implementations. Or maybe someone deeper in the XSF has knowledge about any
requirements in the process regarding this, I haven’t looked it up.
kind regards & thanks,
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: This is a digitally signed message part.
More information about the Standards