%ents; ]>
MUC Affiliations Versioning This specification provides a way to reduce the amount of queries necessary to stay up-to-date with affiliations in a MUC room. &LEGALNOTICE; 0463 Experimental Standards Track Standards Council XEP-0030 XEP-0045 NOT_YET_ASSIGNED &pep.; &larma; 0.1.0 2022-03-08 XEP Editor (jsc) Accepted by vote of Council on 2022-02-16. 0.0.1 2022-02-12 pep

First draft.

Affiliations are a way in &xep0045; to handle permissions (ownership, membership, etc.). Currently, an observer gets the data in presence of online participants at the time of join, of new participants when they join, or when affiliation is changed. This observer has to send in one query per category (owner, admin, member, outcast) if they want to get a full view.

Caching this data can be tricky, as any member removed when the observer is offline is not likely to be caught until the 4 queries are run again. Having multiple queries can also produce race conditions where an occupant is moved out of a group (e.g., owners) to another group (e.g., members) while an observer queries, and they end up not seeing this occupant at all, or twice, or not in the correct group.

Affiliations have become more and more used lately, for example in so-called private groupchats, that is, a non-public, non-anonymous (visible JIDs), members-only room. Having to run all queries is particularly annoying in these private rooms where some implementations prefer to display all participants instead of online participants only, and where the affiliations list is used to know whom to encrypt to in an e2ee context.

This specification sets a versioning mechanism in place, allowing an observer in a room to get the latest changes from a known version, and to reduce the amount of round-trips to handle affiliations.
Full response
A response including the complete affiliation list.
Boostrap request
A request asking for a full reponse.

A server implementing this specification MUST advertise the &mav0; as a &xep0030; feature on the &xep0045; room JID itself.

When sending a join presence to a &xep0045; room, a client may include a since attribute in the &mav0; namespace on the <x xmlns='&muc;'> element. This attribute, a unique and opaque string, indicates the last affiliation version sent by the server that the client has seen, and cached. Sending an empty since attribute is a called bootstrap request, which asks the server for a full response.

This since attribute MUST NOT be broadcasted by the server to other participants. A room not stripping the attribute may disclose information about an occupant to other participants, even though this information is not intended for them.

]]> ]]>

Returning the list of affiliation changes is done as a &MESSAGE; stanza inside the <x xmlns='&muc-user;'> element to which since and/or until attributes of namespace &mav0; MAY be added. Each affiliation is to be sent as an <item> element in the same namespace as its x parent, and MUST at least contain a jid attribute and an affiliation attribute, similarly to what is specified in MUC Affiliations.

The since attribute is used to reflect the version sent by the client and is the starting point of the diff that will be computed. The until attribute is the latest version the server has. When these attributes are present they MUST contain a valid version string (unique and opaque).

The reponse MUST be sent during the join process before any &PRESENCE; is sent to the joining user.

If a client sends a version that the server doesn't know, (e.g., because it only stores the last N versions, or the client made a mistake), the response MUST be a full response, with the since attribute not present, and the until attribute filled with the latest version.

If both attributes have the same value, meaning a client already has the latest version, the x element MUST be empty, only containing the two filled attributes.

There can be no empty diff but there can be empty full reponses (no affiliations).

]]> ]]> ]]>

A new unique (to the room) version string MUST be generated for every affiliation change and included in the broadcast of this change.

When broadcasting an affiliation change (as a &PRESENCE; or &MESSAGE;), on the <x xmlns='&muc-user;'>, a MUC room MUST add the since attribute in the &mav0; namespace, containing the original version string (before the affiliation change), and the new version string (after the affiliation change) in the until attribute (of the same namespace).

Affiliation changes broadcasted to room occupants as &MESSAGE; defined as a MAY in &xep0045;, for example in Granting Owner Status, Granting Admin Status, or Revoking Admin Status, MUST be supported by the MUC room when implementing this specification.

]]>

Permissions are handled as with affiliation iq queries in &xep0045;, the same rules should be applied by the server when deciding who can use this protocol.

Some notes regarding permissions can be find in &xep0045;, for example in Affiliations, or Modifying the member list.

An auth forbidden error MUST be returned in a &MESSAGE; stanza if an observer doesn't have the necessary permissions to request affiliations.

]]>

An observer has to join the MUC room to use the protocol as the since element must be included in the join presence. This makes this specification less prone to vulnerabilities that may have happened with protocols such as MAM in the past (i.e., scraping information without being joined).

A server should be careful not to disclose past affiliation states. If an observer requests a version of which they weren't a part of, a server MUST return an error as specified in Error Cases.

When caching server responses, a client should make sure to associate the received version string to the room JID and not have a global cache for affiliation versions to prevent any cache poisoning issues.

This document requires no interaction with the &IANA;.

The XMPP Registrar includes the &mav0; namespace in its registry of protocol namespaces at https://xmpp.org/registrar/namespaces.html.

This specification is based on the design of roster versioning, with the difference of since and until attributes, to ensure clients stay in sync because unlike roster versioning this may be running over c2s, and s2s which may break.

The <x xmlns='http://jabber.org/protocol/muc[#user]/> elements are not defined extensible in the &xep0045; specification, but as this is a negociated change there shouldn't be any issue.

TODO? RSM. Pagination may have been useful for large rooms, when receiving a full response. Versioning will reduce the amount of bandwidth used for further queries though.

 The protocol documented by this schema is defined in XEP-xxxx: https://xmpp.org/extensions/xep-xxxx.html. ]]>

Thanks to Emmanuel Gil Peyrot and Matthew Wild for the valuable feedback.