[Standards] Proposed XMPP Extension: MUC presence versioning

Georg Lukas georg at op-co.de
Wed Apr 1 18:36:41 UTC 2020


* JC Brand <lists at opkode.com> [2020-04-01 20:07]:
> 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.

Right, but there is no way to discover that on the client side ;-)

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

A modern client needs to fetch the member list anyway, and some rooms
(looking at Bifröst) have many members in them. Optional presence for
non-members is a nice optional add-on, but I would make offline-member
presence mandatory as part of this spec to remove the membership polling
requirement.

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

Yes, the reset token must precede any occupant presence sent to the
user. I've heard that some MUCs are abusing presence-from-the-room-JID
to notify clients of a MUC avatar, and this hasn't killed too many
clients (yaxim used to crash on a nick-less presence ;))

We might add a reset indicator of sorts into this presence and move it
to the first position.

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

I don't like this particularly as it adds yet another round-trip, but
it's probably less broken than any hacked-up pseudo-presence in the
beginning of the occupant presence list.

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

Yes, that would be great.


I also agree with Marvin that it would be cleaner to add a dedicated
element into the presence (or into the <x/> element) than to add a new
property into an existing element. OTOH, it would also add even more
bloat to the <presence> element and we don't have any kind of stream
compression ;-)



Georg
-------------- 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/4101311d/attachment.sig>


More information about the Standards mailing list