Re: [Standards] Proposed XMPP Extension: MUC presence versioning
On Mittwoch, 1. April 2020 20:36:41 CEST Georg Lukas wrote:
> * JC Brand [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 element) than to add a new
> property into an existing element. OTOH, it would also add even more
> bloat to the 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 .
If only we had namespaced attributes (though that likely would not save any
bytes here).
kind regards,
Jonas
signature.asc
Description: This is a digitally signed message part.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___
Re: [Standards] Proposed XMPP Extension: MUC presence versioning
Hi, This is indeed a really nice XEP that could have a big impact during the connection or reconnection. I was actually wondering if the mechanism could be extended to the Roster presences as well? I can imagine that server side (and by extension client side as well) the implementation would not be that different. When you have a big Roster like my account (~450 contacts) it could save a few seconds after the authentication. Regards, Timothée Jaussoin On 31/03/2020 20:35, Jonas Schäfer (XSF Editor) wrote: The XMPP Extensions Editor has received a proposal for a new XEP. Title: MUC presence versioning Abstract: This specification defines a versioning mechanism which reduces the amount of presence traffic in a XEP-0045 MUC URL: https://xmpp.org/extensions/inbox/muc-presence-versioning.html The Council will decide in the next two weeks whether to accept this proposal as an official XEP. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___ ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: MUC presence versioning
* JC Brand [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 element) than to add a new property into an existing element. OTOH, it would also add even more bloat to the 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 ___
Re: [Standards] Proposed XMPP Extension: MUC presence versioning
On 01.04.20 16:27, Georg Lukas wrote: Hi together, * Jonas Schäfer [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
Re: [Standards] Proposed XMPP Extension: MUC presence versioning
Hi,
Very much appreciate people working on MUC again. This feature is
definitely needed.
Nitpicking on the syntax: The current XEP suggests to add the ver
attribute to the {http://jabber.org/protocol/muc}:x and
{http://jabber.org/protocol/muc#user}:x elements. IMO, it would be
better to put a new element either inside the x element or next to it.
Cheers,
Marvin
On 3/31/20 8:35 PM, Jonas Schäfer (XSF Editor) wrote:
> The XMPP Extensions Editor has received a proposal for a new XEP.
>
> Title: MUC presence versioning
> Abstract:
> This specification defines a versioning mechanism which reduces the
> amount of presence traffic in a XEP-0045 MUC
>
> URL: https://xmpp.org/extensions/inbox/muc-presence-versioning.html
>
> The Council will decide in the next two weeks whether to accept this
> proposal as an official XEP.
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___
Re: [Standards] Proposed XMPP Extension: MUC presence versioning
On 4/1/20 4:27 PM, Georg Lukas wrote: >>> 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. Ah, yes that makes sense. So indeed a feature discovery is apparently not necessary to use this extension if the MUC service sends the 'ver' attribute unconditionally. I would still keep the feature in disco#info, just to have it discoverable for feature stat surveys (but maybe only on the MUC service address's disco#info reponse?). - Florian ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: MUC presence versioning
Hi together, * Jonas Schäfer [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 ___
Re: [Standards] Proposed XMPP Extension: MUC presence versioning
On 01.04.20 08:48, Philipp Hancke wrote: Am 31.03.20 um 20:35 schrieb Jonas Schäfer (XSF Editor): The XMPP Extensions Editor has received a proposal for a new XEP. Title: MUC presence versioning Abstract: This specification defines a versioning mechanism which reduces the amount of presence traffic in a XEP-0045 MUC URL: https://xmpp.org/extensions/inbox/muc-presence-versioning.html The Council will decide in the next two weeks whether to accept this proposal as an official XEP. 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? IMO you should already be doing disco for a MUC before joining it, so this doesn't add much extra work and it has the advantage of adhering to the prevailing convention. Or is that to avoid MUC rooms not understanding this feature broadcasting it as part of the presence? I didn't explicitly think of this, but in general I think it's helpful to have the ability to know beforehand what features a MUC supports. (a MUC should also remove this attribute before broadcasting since this would otherwise leak a tiny bit of information about the last join) I'll add this to the security considerations section. -JC ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: MUC presence versioning
On 4/1/20 8:48 AM, Philipp Hancke wrote: > Am 31.03.20 um 20:35 schrieb Jonas Schäfer (XSF Editor): >> The XMPP Extensions Editor has received a proposal for a new XEP. >> >> Title: MUC presence versioning >> Abstract: >> This specification defines a versioning mechanism which reduces the >> amount of presence traffic in a XEP-0045 MUC >> >> URL: https://xmpp.org/extensions/inbox/muc-presence-versioning.html >> >> The Council will decide in the next two weeks whether to accept this >> proposal as an official XEP. > > 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. While when using disco#info, the client can discover the feature and bootstrap that protocol extension with 'ver' set to the empty string (ver=""), without having joined the MUC before. Seems reasonable to me. - Florian ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: MUC presence versioning
Am 31.03.20 um 20:35 schrieb Jonas Schäfer (XSF Editor): The XMPP Extensions Editor has received a proposal for a new XEP. Title: MUC presence versioning Abstract: This specification defines a versioning mechanism which reduces the amount of presence traffic in a XEP-0045 MUC URL: https://xmpp.org/extensions/inbox/muc-presence-versioning.html The Council will decide in the next two weeks whether to accept this proposal as an official XEP. 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? Or is that to avoid MUC rooms not understanding this feature broadcasting it as part of the presence? (a MUC should also remove this attribute before broadcasting since this would otherwise leak a tiny bit of information about the last join) Overall this seems like a quite useful reinterpretation of the original MUC semantics. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: MUC presence versioning
On Dienstag, 31. März 2020 21:54:41 CEST Sam Whited wrote: > The link appears to be broken. Thanks for letting us know. Due to the server outage two weeks back the update of XEPs on the server is still slower than usual. I didn’t expect this, otherwise I wouldn’t have sent the emails yet. I hope that the update will be pulled to the server within the next few hours. Thank you for your partience and kind regards, Jonas signature.asc Description: This is a digitally signed message part. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: MUC presence versioning
The link appears to be broken. —Sam On Tue, Mar 31, 2020, at 14:35, Jonas Schäfer wrote: > The XMPP Extensions Editor has received a proposal for a new XEP. > > Title: MUC presence versioning > Abstract: > This specification defines a versioning mechanism which reduces the > amount of presence traffic in a XEP-0045 MUC > > URL: https://xmpp.org/extensions/inbox/muc-presence-versioning.html > > The Council will decide in the next two weeks whether to accept this > proposal as an official XEP. > ___ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > ___ > -- Sam Whited ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
