* JC Brand <li...@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
signature.asc
Description: PGP signature
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
