Incorporate feedback from the standards list
+- 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. + 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;. + <presence/> stanzas might still contain useful metadata, such as the user's affiliation or &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. + A client that supports MUC presence versioning needs to keep track and store the presence states 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 corresponding 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. + If MUC presence versioning is supported, the client MAY include a <version> tag with a 'ver' attribute set to the last known version + inside the <{http://jabber.org/protocol/muc#user}x> tag of the <presence/> stanza, which it sends to join the MUC.
+ If MUC 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. + <version> tag with a 'ver' attribute set to the latest version number inside the <{http://jabber.org/protocol/muc#user}x> tag. + The client must save the version number (and continuously update with never versions as they're received) and use that 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. + 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 implements presence versioning, it MUST specify the 'urn:xmpp:muc-presence-versioning:0' feature in its service discovery information features, + as specified in &xep0030;.
+ A MUC that supports presence versioning MUST broadcast presence for all affiliated users, including those who are currently 'unavailable'. + XEP-0045 documents the status code '102', which is used to indicate that a MUC shows unavailable members. +
++ The only exception is when a MUC has been explicitly configured to only broadcast presence from occupants above a certain affiliation, + (see the presence broadcast section of XEP-0045). +
++ In order for a user to permanently join a room, and therefore become affiliated so that they are included in presence broadcasts, + they MAY be allowed to register themselves as members in the MUC. + XEP-0045 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. +
++ If a MUC receives a presence version number that's so old, that it no longer has the corresponding state available, + it MUST include a <reset> token in the first <presence> stanza it sends (regardless of whom in the MUC the presence relates to). + The first presence stanza MAY be from the MUC itself (as shown in the example below). + Afterwards, the MUC MUST then send all presences (including 'unavailable' for affiliated users) as if the client is starting from a blank slate. +
+ +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.
++ Even if the client did not include a <version> tag with a 'ver' attribute in its "join" <presence/> stanza, + the server SHOULD still return a <version> tag with 'ver' attribute (set to the latest version number) + on all relevant <presence/> stanzas. + This allows clients to bootstrap MUC presence versioning without having to do a service discovery query first. +
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. + In some cases, the presence states being kept track of by the MUC service MAY be reduced to a minimum of only two states, 'available' and 'unavailable'. + This can drastically reduce the number of states the server needs to keep track off, at the cost of not allowing users to provide more fine-grained + reporting of their level of availability.
- 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. + The MUC service should strip the <version> tag from the user's <presence> before relaying it to other occupants, + to avoid leaking information on when last the user joined the MUC.
- - -- 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. -
-