XEP-0463: MUC Affiliations Versioning

1. Introduction¶

Affiliations are a way in Multi-User Chat (XEP-0045) [1] 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.

2. Requirements¶

• Reduce the number of round-trips necessary to get the list of affiliations.
• Allow an implementation to request a diff of affiliations since a known version.

3. Glossary¶

4. Discovering Support¶

A server implementing this specification MUST advertise the urn:xmpp:muc:affiliations:0 as a Service Discovery (XEP-0030) [2] feature on the Multi-User Chat (XEP-0045) [1] room JID itself.

5. Usage Flow¶

<presence to='news@chat.commons.example' from='louise@commons.example/desktop'>
  <x xmlns='http://jabber.org/protocol/muc'
     xmlns:mav='urn:xmpp:muc:affiliations:0'
     mav:since='' />
</presence>

<presence to='news@chat.commons.example' from='rosa@commons.example/toaster'>
  <x xmlns='http://jabber.org/protocol/muc'
     xmlns:mav='urn:xmpp:muc:affiliations:0'
     mav:since='9pacabr2q1' />
</presence>

<message from='news@chat.commons.example'
         to='louise@commons.example/desktop'>
  <x xmlns='http://jabber.org/protocol/muc#user'
     xmlns:mav='urn:xmpp:muc:affiliations:0'
     mav:until='ruz41312vw'>
    <item jid='louise@commons.example' affiliation='owner' />
    <item jid='peter@commons.example' affiliation='owner' />
    <item jid='rosa@commons.example' affiliation='owner' />
  </x>
</message>

<message from='news@chat.commons.example'
         to='louise@commons.example/desktop'>
  <x xmlns='http://jabber.org/protocol/muc#user'
     xmlns:mav='urn:xmpp:muc:affiliations:0'
     mav:since='9pacabr2q1'
     mav:until='ruz41312vw'>
    <item jid='vladimir@commons.example' affiliation='none' />
    <item jid='rosa@commons.example' affiliation='owner' />
  </x>
</message>

<message from='news@chat.commons.example'
         to='louise@commons.example/desktop'>
  <x xmlns='http://jabber.org/protocol/muc#user'
     xmlns:mav='urn:xmpp:muc:affiliations:0'
     mav:until='ruz41312vw'/>
</message>

<message from='news@chat.commons.example'
         to='louise@commons.example/desktop'>
  <x xmlns='http://jabber.org/protocol/muc#user'
     xmlns:mav='urn:xmpp:muc:affiliations:0'
     mav:since='9pacabr2q1'
     mav:until='ruz41312vw'>
    <item jid='peter@commons.example/mobile' affiliation='none' role='none'/>
  </x>
</message>

<message from='news@chat.commons.example'
         to='vladimir@commons.example/web'
         id='foo' type='error'>
  <error by='news@chat.commons.example' type='auth'>
    <forbidden xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</message>

6. Security Considerations¶

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.

7. IANA Considerations¶

This document requires no interaction with the the Internet Assigned Numbers Authority (IANA) [3].

8. XMPP Registrar Considerations¶

The XMPP Registrar includes the urn:xmpp:muc:affiliations:0 namespace in its registry of protocol namespaces at https://xmpp.org/registrar/namespaces.html.

9. Design Considerations¶

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) [1] 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.

10. XML Schema¶

<?xml version='1.0' encoding='UTF-8'?>

<xs:schema
  xmlns:xs='http://www.w3.org/2001/XMLSchema'
  targetNamespace='urn:xmpp:muc:affiliations:0'
  xmlns='urn:xmpp:muc:affiliations:0'
  elementFormDefault='qualified'>

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

  <!-- TODO: How do I schematize standalone attributes? -->
  </xs:element>
</xs:schema>

11. Acknowledgements¶

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

Appendices

Appendix A: Document Information¶

Series

XEP

Number

0463

Publisher

XMPP Standards Foundation

Status

Experimental

Type

Standards Track

Version

0.1.0

Last Updated

2022-03-08

Approving Body

XMPP Council

Dependencies

XEP-0030, XEP-0045

Supersedes

None

Superseded By

None

Short Name

NOT_YET_ASSIGNED

Source Control

HTML

This document in other formats: XML  PDF

Appendix B: Author Information¶

Maxime Buquet

Email

pep@bouah.net

JabberID

pep@bouah.net

Marvin Wißfeld

Email

xmpp@larma.de

JabberID

jabber@larma.de

Appendix C: Legal Notices¶

Appendix D: Relation to XMPP¶

The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 6120) and XMPP IM (RFC 6121) specifications contributed by the XMPP Standards Foundation to the Internet Standards Process, which is managed by the Internet Engineering Task Force in accordance with RFC 2026. Any protocol defined in this document has been developed outside the Internet Standards Process and is to be understood as an extension to XMPP rather than as an evolution, development, or modification of XMPP itself.

Appendix E: Discussion Venue¶

The primary venue for discussion of XMPP Extension Protocols is the <standards@xmpp.org> discussion list.

Discussion on other xmpp.org discussion lists might also be appropriate; see <https://xmpp.org/about/discuss.shtml> for a complete list.

Errata can be sent to <editor@xmpp.org>.

Appendix F: Requirements Conformance¶

The following requirements keywords as used in this document are to be interpreted as described in RFC 2119: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", "OPTIONAL".

Appendix G: Notes¶

Appendix H: Revision History¶

Note: Older versions of this specification might be available at https://xmpp.org/extensions/attic/

1. Version 0.1.0 (2022-03-08)¶
   Accepted by vote of Council on 2022-02-16.
   XEP Editor (jsc)
2. Version 0.0.1 (2022-02-12)¶

   First draft.

   pep

Appendix I: Bib(La)TeX Entry

@report{buquet2022xep0463,
  title = {MUC Affiliations Versioning},
  author = {Buquet, Maxime and Wißfeld, Marvin},
  type = {XEP},
  number = {0463},
  version = {0.1.0},
  institution = {XMPP Standards Foundation},
  url = {https://xmpp.org/extensions/xep-0463.html},
  date = {2022-02-12/2022-03-08},
}

END