From 8632dd9e4be253032054cc7e7a96645ab142c6ac Mon Sep 17 00:00:00 2001 From: JC Brand Date: Mon, 30 Mar 2020 12:35:16 +0200 Subject: [PATCH] New ProtoXEP: MUC presence versioning --- inbox/muc-presence-versioning.xml | 190 ++++++++++++++++++++++++++++++ 1 file changed, 190 insertions(+) create mode 100644 inbox/muc-presence-versioning.xml diff --git a/inbox/muc-presence-versioning.xml b/inbox/muc-presence-versioning.xml new file mode 100644 index 00000000..361197c7 --- /dev/null +++ b/inbox/muc-presence-versioning.xml @@ -0,0 +1,190 @@ + + +%ents; +]> + + +
+ MUC presence versioning + This specification defines a versioning mechanism which reduces the amount of presence traffic in a XEP-0045 MUC + &LEGALNOTICE; + xxxx + ProtoXEP + Standards Track + Standards + Council + + XMPP Core + XMPP IM + XEP-0045 + + + + omnipresent-muc-affiliates + &jcbrand; + &mwild; + + 0.0.1 + 2020-03-30 + jcb +

First draft

 + +
+ +

+ Many modern-day non-XMPP groupchat implementations have discarded the metaphor of physical presence inside a room that a user must enter and exit, as implemented by &xep0045;. + The newer &xep0369; has therefore made presence subscriptions optional. +

+

+ Often it no longer makes sense for a chat service to require that a user is "present" in order for them to be addressed by other occupants or to receive messages, + especially if the chat implementation will inform you out-of-band, for example via push notifications or email. + The notion of "room presence" is therefore less relevant than before, and in some cases can be done away with entirely. +

+

+ Broadcasting all XEP-0045 MUC participants' presences to one another scales quadratically (O(n^2)) and can greatly increase the amount of network traffic, for potentially negligable gain. +

+

+ Even though the metaphorical concept of presence inside a room might no longer be relevant for a groupchat implementation, + <presence/> stanzas might still contain useful metadata, such as the user's affiliation or their &xep0317;. +

+

+ This XEP defines a versioning mechanism (similar to roster versioning in &rfc6121;) whereby the amount of presence traffic in a MUC may be greatly reduced. + It also describes additional measures which may be taken to further reduce the amount of presence traffic. +

+ + + +

+ A client that supports presence versioning needs to keep track and store the presence statuses of all MUC occupants, across multiple MUC sessions. + Similarly, a MUC service which supports presence versioning will also need to maintain a changelog of version numbers and presence states. +

+

+ Before the client enters a MUC, it SHOULD use service discovery to check whether presence versioning is supported + (see determining support below.). + If presence versioning is supported, the client MAY include a 'ver' attribute set to the last known presence version + in the <{http://jabber.org/protocol/muc}x> tag of the <presence/> stanza, which it sends to join the MUC. +

+

+ If presence versioning is not supported by the server, the client MUST NOT include a 'ver' attribute. +

+

+

+ + + + +]]> + +

+ The MUC will return only those presences that have changed since the version indicated by the client, and in the self-presence of the joining user it will add a + 'ver' attribute with the latest version number on the <{http://jabber.org/protocol/muc}x> tag. The client must save the version number and use it next time it joins the MUC. +

+ + + + + + + +]]> + +

+ When presence versioning is enabled, every subsequent <presence/> stanza sent by the server MUST include a new version number, which replaces the existing one saved by the client. +

+ + + +

If a MUC implements presence versioning, it MUST specify the 'urn:xmpp:muc-presence-versioning:0' feature in its service discovery information features, as specified in &xep0030;.

+ + + ]]> + + + + ... + + ... + + ]]> + + + +

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.

+

+ If the client has not yet saved a presence version number and the corresponding presence states, + then it MUST bootstrap presence versioning by sending a 'ver' attribute set to the empty string (i.e., ver=""). +

+

+ Even if the client did not include a 'ver' attribute in its "join" <presence/> stanza, the server SHOULD still set a 'ver' attribute on the relevant <presence/> stanzas. +

+ + + +

+ There are a number of &xep0045; features that a client and server may decide to configure and/or implement in order to further reduce the number of presence stanzas being sent around. +

+ + + +

+ A MUC MAY be configured to only broadcast presence from occupants above a certain affiliation, + (see the presence broadcast section of XEP-0045), + for example in a MUC where non-affiliated users are allowed to view the discussion but aren't allowed to send messages. +

+ +

+ This step can be taken in addition to letting users register themselves as members in the MUC. + XEP-45 describes in section 7.10 "Registering with a Room how a user may register themselves with a room, + thereby receiving the "member" affiliation and having their preferred nickname reserved in that room. +

+ + + + +

+ In some cases, it makes sense to reduce the number of presence statuses to only a subset, in order to reduce to total amount of states the server needs to keep track off. + In the simplest case, this would mean keeping track only of two statuses, 'available' and 'unavailable'. +

+ +

+ XEP-0045 documents the status code 102, which is used to indicate that a room shows unavailable members. + By also sending to newly joined users the presence stanzas of unavailable members, + it's possible to provide any necessary presence metadata of all relevant users in a groupchat and not just the currently "present" users. +

+ + + + + +

None.

+ + + + +

The ®ISTRAR; includes 'urn:xmpp:muc-presence-versioning:0' in its registry of protocol namespaces (see &NAMESPACES;).

+
    +
  • urn:xmpp:muc-presence-versioning:0
    • +
+ + + &NSVER; + + +