[Standards] Proposed XMPP Extension: MUC presence versioning

JC Brand lists at opkode.com
Wed Apr 1 18:07:02 UTC 2020

On 01.04.20 16:27, Georg Lukas wrote:
> Hi together,
> * Jonas Schäfer <jonas at wielicki.name> [2020-03-31 20:39]:
>> Title: MUC presence versioning
> This is an awesome extension to the MUC protocol, and I think it fits in
> well. Next step is to re-organize the MUC membership query from four IQs
> to something with differential semantics as well ;)

This protoXEP comes from discussions I had with Matthew Wild about this.

I was wondering about implementing versioning for the membership lists,
and then Matthew suggested presence versioning instead.

He deserves credit for the good ideas in here.

> Re disco#info:
>>> While I understand that we all love disco, wouldn't it be easier
>>> to only send the ver attribute if one was received from the muc in
>>> the past?
>> That would require that the client received a presence before from the
>> MUC, i.e., that the client joined the MUC room before.
> The client doesn't know a @ver value anyway when joining for the first
> time, and in absense of a @ver, the server will send the full presence
> list. This would of course break Business Rule #2, for which I can't see
> any rationale.
> If the server will always add @ver, regardless of client-side support
> indication for Presence Versioning, then a supporting client can flag
> the MUC as capable and store the last received @ver element solely based
> on its existence, without an extra disco#info roundtrip.
I'm not sure about other clients, but Converse.js does a disco#info in any
case before joining a MUC, so it's not an extra roundtrip.

However, a client can opt to not do a disco query at all and simply check
whether it gets a 'ver' attribute back, like you and others have described.

I'll update the protoXEP text to make it clear that supporting MUCs should
always return a 'ver' attribute for this very reason.

>  From section 4:
> | If a MUC receives a presence version number that's so old, so that it
> | no longer has the corresponding state available, it needs to send all
> | presence statuses back to the client.
> The server needs to prepend some kind of reset token to that, otherwise
> the client will interpret the new presence as a delta to its existing
> stored presence, and keep ghosts of the users that left since the client
> left.
Yes, this would be necessary unless the additional measures in the bottom of
of the protoXEP are implemented.

If the server only sends presence for affiliated users (see 5.1) and 
also sends
unavailable presences (see 5.2.1), then ghost users won't be created.

I was however reluctant to make these two criteria required for message 
which is why I added them to "additional measures".

Not all MUCs will want to configure themselves this way, but it's IMO a 
good way to implement a Slack-style MUC.

But for the cases where MUCs aren't configured in this way,
we'd need something like the reset token you mentioned.

However, if the reset token is received too late, then the client might 
already have
acted on false assumptions on the presence stanzas it received before 
the reset token.

So the reset token needs to be the first thing the client sees, so that 
it can
act accordingly (for example by wiping the slate clean) before the 
presences start
coming in.

The 'ver' attribute comes with your self-presence stanza and initially I 
thought of
putting the reset token there, if that was always received first, then 
it wouldn't be
a problem, but this isn't currently a requirement anywhere AFAIK.

Alternatively, the MUC should return an error presence if the version
is no longer cached and the client should then send a new join presence
without a 'ver' attribute.

Any thoughts on this?

> This would be a repetition of failure mode #2 of GroupChat 1.0 -
> see https://mail.jabber.org/pipermail/standards/2017-October/033501.html
>  From §5.2.1:
> | it's possible to provide any necessary presence metadata of all
> | relevant users in a groupchat and not just the currently "present"
> | users.
> This sounds like the opposite of the goal of §5, which is to reduce the
> number of stanzas sent.
Yes when read in isolation, but when taking into consideration what I 
wrote above
I believe the intent will be more clear.

I'll try to make this more clear in the document.

> The right rationale would probably be to let the client know of all
> members of the MUC and their respective roles. If we make that feature
> discoverable and integrated into Presence Versioning, the client doesn't
> need to run four IQ queries for owner, admin, member and outcast.

Yes, this pretty much sums up the need for what's in the "additional 
measures" section.

If the MUC could always send all presences (including offline ones)
for affiliated users, and then also include a reset token when sending 
the full
presence state, then we can avoid the 4 IQ queries and ghost users.

So I think I need to move 5.1 from "additional measures" to "requirements"
and change "Only" to "Always". And then move 5.2.1 also to "requirements"
and make clear that it's only for affiliated users.

> I'd actually say that integrating this into Presence Versioning and
> giving some nice examples would be most of what's needed to prevent
> querying long lists of things on each join.
Yes, thanks for the feedback.


More information about the Standards mailing list