XEP-xxxx: End-to-End Encrypted Contacts Metadata

1. Introduction¶

Roster is a central component of the XMPP specifications, serving as the mechanism for indicating to the server and other devices who we know, along with associated metadata and presence permission data. While convenient, this information carries significant privacy implications. In the context of ongoing efforts to reduce metadata exposure in XMPP, this document specifies a method for managing contact data in a more privacy-respectful way by using end-to-end encryption, while retaining the original roster mechanism described in RFC 6121 [1] for server-required features and backward compatibility.

2. Requirements¶

The design goals of this XEP are:

• Reduce metadata exposure: no contact data should be exposed to server beyond what is required for presence permission and backward compatibility.
• Mandatory end-to-end encryption.
• Contact data must not be tied to a JID or any domain-specific identifier.
• The mechanism must be usable in serverless configurations, without relying on server-side storage or processing of contact data.

3. Design Decisions¶

A few words to explain the design decisions. There are basically two ways to encrypt contact metadata:

1. By using the existing roster mechanism, adding a new element to handle metadata, and implementing end-to-end encryption for this element.
2. By implementing another metadata mechanism, exploiting other XMPP mechanisms. Publish-Subscribe (XEP-0060) [2] is the most suitable one for this use case.

Option 2 has been chosen for the following reasons:

• The <item/> element of the roster mechanism, as specified in RFC 6121 [1] §2.1.2, has a mandatory "jid" element, and as per requirements we don't want to tie contact data to a JID.
• The roster's <item/> element has not been explicitly designed to accept extra elements, and most implementations probably do not support them. While this could be added, there is a risk that some implementations remove unknown elements, and it would take years for the entire ecosystem to support them. Even then, there will always be a risk that an old client removes unknown metadata, as experience has shown with legacy bookmark mechanisms (with Bookmark Storage (XEP-0048) [3] clients could remove unknown elements).
• There is no end-to-end encryption mechanism for roster. While this could be added, it would certainly bring compatibility issues with existing implementations, would still leave the JID visible in clear text (as it is mandatory on the <item/> element), and would require additional extensions. On the other hand, there are already end-to-end encryption mechanisms for Publish-Subscribe (XEP-0060) [2] (notably OpenPGP for XMPP Pubsub (XEP-0473) [4]).

4. Service and Well-Known Nodes¶

Encrypted contacts use two well-known nodes:

• urn:xmpp:contacts where contact information is stored.
• urn:xmpp:contacts-groups where groups used to classify contacts are stored.

These nodes MUST be set on the Personal Eventing Protocol (XEP-0163) [5] service (except in serverless configurations, where they MAY be set on another relevant pubsub service, see Business Rules), and MUST follow Best Practices for Persistent Storage of Private Data via Publish-Subscribe (XEP-0223) [6]. The IDs used for the pubsub items MUST NOT have any semantic meaning, and in particular MUST NOT be derived from any contact-related data.

Both node items MUST be end-to-end encrypted. The currently recommended method is using OpenPGP for XMPP Pubsub (XEP-0473) [4] as OX is well adapted for this use case. However, another encryption method MAY be used in the future if proven better.

<iq type='set'
  from='romeo@example.net/orchard'
  to='romeo@example.net'
  id='contact1'>
  <pubsub xmlns='http://jabber.org/protocol/pubsub'>
    <publish node='urn:xmpp:contacts'>
      <item id='a1b2c3d4'>
        <contact xmlns='urn:xmpp:contacts:0' name='Juliet Capulet'>
          <identity type='jid'>juliet@example.org</identity>
          <group id='grp-789'/>
          <group id='grp-123'/>
        </contact>
      </item>
    </publish>
  </pubsub>
</iq>

<iq type='set'
  from='romeo@example.net/orchard'
  to='romeo@example.net'
  id='group1'>
  <pubsub xmlns='http://jabber.org/protocol/pubsub'>
    <publish node='urn:xmpp:contacts-groups'>
      <item id='grp-789'>
        <group xmlns='urn:xmpp:contacts:0' id='grp-789' name='Friends'/>
      </item>
      <item id='grp-123'>
        <group xmlns='urn:xmpp:contacts:0' id='grp-123' name='House of Capulet'/>
      </item>
    </publish>
  </pubsub>
</iq>

<iq type='set'
  from='romeo@example.net/orchard'
  to='romeo@example.net'
  id='reserved1'>
  <pubsub xmlns='http://jabber.org/protocol/pubsub'>
    <publish node='urn:xmpp:contacts'>
      <item id='a1b2c3d5'>
        <reserved xmlns='urn:xmpp:contacts:0'/>
      </item>
    </publish>
  </pubsub>
</iq>

5. Business Rules¶

• The RFC 6121 [1] roster mechanism is still used, as it is necessary for presence permission handling and backward compatibility. However, when encrypted contacts metadata are used, the roster should be kept minimal: the 'name' attribute and <group/> element SHOULD NOT be used. Instead, an encrypted contact with the same JID SHOULD be used to store the name and group metadata.
• As random IDs are used, it is possible that two or more <contact/> elements referring to the same contact are published (e.g., due to a race condition between two clients updating the same contact). In this case, the receiving client MUST merge the data from both elements (overwriting data from the previous item in case of conflict, in the order of item reception). The receiving client MAY overwrite the last seen <contact/> element with the result of the merge, and MAY either delete the older items or replace them with <reserved/> elements.
• In serverless setups, as there is no server to offer a PEP service, the well-known node may be placed on whichever service is used to replace Personal Eventing Protocol (XEP-0163) [5].

6. Discovering Support¶

If a client supports encrypted contacts, it MUST advertise it by including the "urn:xmpp:contacts:0" discovery feature in response to a Service Discovery (XEP-0030) [7] information request:

<iq type='get'
    from='juliet@example.org/balcony'
    to='romeo@montague.lit/orchard'
    id='disco1'>
  <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>

<iq type='result'
    from='romeo@montague.lit/orchard'
    to='juliet@example.org/balcony'
    id='disco1'>
  <query xmlns='http://jabber.org/protocol/disco#info'>
    ...
    <feature var='urn:xmpp:contacts:0'/>
    ...
  </query>
</iq>

7. Security Considerations¶

The security consideration of used XEPs apply here and must be carrefully checked, in paritcular the ones from Publish-Subscribe (XEP-0060) [2] Best Practices for Persistent Storage of Private Data via Publish-Subscribe (XEP-0223) [6] and OpenPGP for XMPP Pubsub (XEP-0473) [4].

8. IANA Considerations¶

This document does not require interaction with the Internet Assigned Numbers Authority (IANA) [8].

9. XMPP Registrar Considerations¶

TODO

10. Acknowledgements¶

This work has been done for the Serverless and Metadata Reduction for XMPP project. Many thanks to NLNet foundation and NGI Zero Core for funding the work on this specification.

11. XML Schema¶

TODO

Appendices

Appendix A: Document Information¶

Series

XEP

Number

xxxx

Publisher

XMPP Standards Foundation

Status

ProtoXEP

Type

Standards Track

Version

0.0.1

Last Updated

2026-01-11

Approving Body

XMPP Council

Dependencies

XMPP Core, XEP-0060, XEP-0163, XEP-0223, XEP-0473

Supersedes

None

Superseded By

None

Short Name

contacts

This document in other formats: XML  PDF

Appendix B: Author Information¶

Jérôme Poisson

Email

goffi@goffi.org

JabberID

goffi@jabber.fr

URI

https://www.goffi.org

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/community/> for a complete list.

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

Appendix F: Requirements Conformance¶

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

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.0.1 (2026-01-11)¶

   First draft.

   jp

Appendix I: Bib(La)TeX Entry

@report{poisson2026contacts,
  title = {End-to-End Encrypted Contacts Metadata},
  author = {Poisson, Jérôme},
  type = {XEP},
  number = {xxxx},
  version = {0.0.1},
  institution = {XMPP Standards Foundation},
  url = {https://xmpp.org/extensions/xep-xxxx.html},
  date = {2026-01-11/2026-01-11},
}

END