[Standards] Proposed XMPP Extension: MUC presence versioning

Jonas Schäfer jonas at wielicki.name
Sun Apr 12 13:06:35 UTC 2020

On Mittwoch, 1. April 2020 20:36:41 CEST Georg Lukas wrote:
> * JC Brand <lists at opkode.com> [2020-04-01 20:07]:
> > 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.

As a middle ground, the MUC could inject a 
<{urn:xmpp:presence-versioning:0}reset/> element in the first presence it 
sends (no matter which occupant it refers to).

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

I think having a separately namespaced element would be a requirement for 
moving this on to draft. Messing with elements in other namespaces is a no-go. 
The natural place for this would be inside the <x/>.

If only we had namespaced attributes (though that likely would not save any 
bytes here).

kind regards,
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.jabber.org/pipermail/standards/attachments/20200412/13e834d3/attachment.sig>

More information about the Standards mailing list