27 Jan
2026
27 Jan
'26
4:18 p.m.
Hi Dan,
Apologies to Goffi, I said at the last Council session
I would pop a message
on list, and then didn't.
No worries, you did actually :)
- I think the introduction could use some more
context. [SNIP]
- I think Design Decisions could use some more background [SNIP]
Agreed.
- 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?>
`jid` is required for Roster's Item, the proposed spec use a different element
(but will reuse the group of Roster's <item> following discussion with
Daniel). JID is a sensitive data (for now we can retrieve JID who send or
receive message, but this may change in the future, notably with sealed
sender).
Roster mechanism is only used for presence data, or if use is willing to use
it e.g. for blocking message from contacts out of roster. The sync is made
with JID in this case, JID is still used in <identity>, it's just not
mandatory. The idea is that the server only know the minimum required to do
its job, but things such as groups or name are encrypted.
- 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?
The contacts MUST be e2e encrypted, it the raison d'être of this specification.
The rest just open the door to a future better encryption method, so we don't
stay forever blocked on OX for pubsub. We have namespaces to deal with that, I
don't see we need much more. Maybe the formulation can be improved, but the
idea is to say that e2ee is mandatory, and that we have a method right now the
must be used as long as there is no better alternative, and the door is open
for better algorithm is any in the future.
I don't think all of these are blockers for
progressing the XEP. I think The
compatible implementations feels like it might be though?
The compatibility with RFC Roster is done though the <identity type="jid">
which is already specified. It could maybe be clear or explained in a dedicated
section.
Btw, I've named the spec "End-to-End Encrypted Contacts Metadata" where
I've
used "Contacts" instead of "Roster" to avoid the confusion with RFC
roster.
Of course I'm partial, but I don't think this is enough to block this spec.
Thanks for your feedback.
Best,
Goffi