On 01.04.20 16:27, Georg Lukas wrote:
Hi together,
* Jonas Schäfer <[email protected]> [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 ;)
This protoXEP comes from discussions I had with Matthew Wild about this.
I was wondering about implementing versioning for the membership lists,
and then Matthew suggested presence versioning instead.
He deserves credit for the good ideas in here.
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.
I'm not sure about other clients, but Converse.js does a disco#info in any
case before joining a MUC, so it's not an extra roundtrip.
However, a client can opt to not do a disco query at all and simply check
whether it gets a 'ver' attribute back, like you and others have described.
I'll update the protoXEP text to make it clear that supporting MUCs should
always return a 'ver' attribute for this very reason.
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.
Yes, this would be necessary unless the additional measures in the bottom of
of the protoXEP are implemented.
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.
I was however reluctant to make these two criteria required for message
versioning,
which is why I added them to "additional measures".
Not all MUCs will want to configure themselves this way, but it's IMO a
pretty
good way to implement a Slack-style MUC.
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.
So the reset token needs to be the first thing the client sees, so that
it can
act accordingly (for example by wiping the slate clean) before the
presences start
coming in.
The 'ver' attribute comes with your self-presence stanza and initially I
thought of
putting the reset token there, if that was always received first, then
it wouldn't be
a problem, but this isn't currently a requirement anywhere AFAIK.
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.
Any thoughts on this?
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.
Yes when read in isolation, but when taking into consideration what I
wrote above
I believe the intent will be more clear.
I'll try to make this more clear in the document.
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.
Yes, this pretty much sums up the need for what's in the "additional
measures" section.
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.
So I think I need to move 5.1 from "additional measures" to "requirements"
and change "Only" to "Always". And then move 5.2.1 also to "requirements"
and make clear that it's only for affiliated users.
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.
Yes, thanks for the feedback.
JC
_______________________________________________
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: [email protected]
_______________________________________________
