[Standards] Proposed XMPP Extension: MUC presence versioning

Georg Lukas georg at op-co.de
Wed Apr 1 14:27:49 UTC 2020

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 ;)

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.

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.  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.

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.

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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20200401/b98ba87e/attachment.sig>

More information about the Standards mailing list