Apologies to Goffi, I said at the last Council session I would pop a
message on list, and then didn't.
Until now...
- I think the introduction could use some more context. It mentions privacy
implications as a key driver for the XEP, but doesn't expand on how.
Inferring from stuff later in the document, I think it's when you don't
trust your server operator, but I think it could be explicit about the
problem being solved.
- We briefly discussed how this could be Step 1 of N towards serverless
operation, where your contact doesn't have a stable JID and/or is
permanently addressable by something that isn't a standard JID.
- I think Design Decisions could use some more background on the bigger
picture of what this is contributing to, and if necessary, how this
contributes toward that goal. I know that's not normal XEP territory, but
given the section is already about background and rationale, I think it
makes sense
- This XEP states "Contact data must not be tied to a JID or any
domain-specific identifier", and RFC 6121 says "The 'jid' attribute of the
<item/> element specifies the Jabber Identifier (JID) that uniquely
identifies the roster item. The 'jid' attribute is REQUIRED whenever a
client or server adds, updates, deletes, or returns a roster item.". The
business rules say that "roster mechanism is still used, as it is
necessary". Does that mean that there's an unspecified sync, or that the
client is maintaining two lists?
- I'm a bit uncomfortable with the text about encryption. "Both node items
MUST be end-to-end encrypted", but then goes on to loosely recommend one
method, and add a MAY that something that isn't a MUST or SHOULD might
change in the future. Does this need either one MUST/SHOULD mechanism to
enable compatible implementations, or a metadata layer to inform the client
of the mechanism?
I don't think all of these are blockers for progressing the XEP. I think
The compatible implementations feels like it might be though?
HTH,
Dan
On Thu, 15 Jan 2026 at 10:38, Daniel Gultsch <[email protected]> wrote:
> The XMPP Extensions Editor has received a proposal for a new XEP.
>
> Title: End-to-End Encrypted Contacts Metadata
> Abstract:
> This specification describes how to encrypt contacts metadata to
> minimize server exposure.
>
> URL: https://xmpp.org/extensions/inbox/contacts-e2e.html
>
> The Council will decide in the next two weeks whether to accept this
> proposal as an official XEP.
> _______________________________________________
> Standards mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
>
_______________________________________________
Standards mailing list -- [email protected]
To unsubscribe send an email to [email protected]
