Hi together, * Jonas Schäfer <jo...@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. Georg
signature.asc
Description: PGP signature
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
