First draft.
Affiliations are a way in Multi-User Chat (XEP-0045)
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.
A server implementing this specification MUST advertise the urn:xmpp:muc:affiliations:0 as a Service Discovery (XEP-0030)
When sending a join presence to a Multi-User Chat (XEP-0045)
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='http://jabber.org/protocol/muc#user'> element to which since and/or until attributes of namespace urn:xmpp:muc:affiliations:0 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='http://jabber.org/protocol/muc#user'>, a MUC room MUST add the since attribute in the urn:xmpp:muc:affiliations:0 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 Multi-User Chat (XEP-0045)
Permissions are handled as with affiliation iq queries in Multi-User Chat (XEP-0045)
Some notes regarding permissions can be find in Multi-User Chat (XEP-0045)
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 the Internet Assigned Numbers Authority (IANA)
The XMPP Registrar includes the urn:xmpp:muc:affiliations:0 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 Multi-User Chat (XEP-0045)
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.