15 Jan
2026
15 Jan
'26
11:37 a.m.
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.
15 Jan
15 Jan
11:52 a.m.
Hi,
On Thu, Jan 15, 2026 at 11:37 AM Daniel Gultsch <daniel(a)gultsch.de> wrote:
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
honestly I’m not entirely sure I like this. My naive implementation
would just stick a bunch of <item xmlns='jabber:iq:roster'
jid='nurse(a)example.com'/> in some sort of wrapper element into on
singleton roster node. No multiple items, not separate node for
groups. Just re-use the same <group/> children from jabber:iq:roster.
I reckon for most medium sized rosters the encryption overhead is the
bottle neck instead of the bandwidths constrains of one items vs
multiple items.
Reusing the namespace and syntax (with groups as children) would allow
me to re-use the roster processing pipeline i already have.
So with my council head I would only accept this XEP if we are either
open of developing this XEP into what I’m outlined above OR if we are
open to at some later point accept an alternative proposal that
describes the above. (And then have the better idea win that way)
cheers
Daniel
12:54 p.m.
New subject: Proposed XMPP Extension: End-to-End Encrypted Contacts Metadata
On 15 Jan 2026, at 10:52, Daniel Gultsch <daniel(a)gultsch.de> wrote:
Hi,
On Thu, Jan 15, 2026 at 11:37 AM Daniel Gultsch <daniel(a)gultsch.de> wrote:
For ’normal’ rosters, I think the many-items thing is an irritation rather than helpful.
For a stpeter roster, though, you could start running into issues with size limits trying
to put everything into a single item, I think? Of course, if you *do* have a
multi-thousand item roster, one item per roster item is also unfortunate, so I suspect
neither of these approaches is truly ideal.
On a different note - I’m curious why, in a spec that’s concerned with reducing metadata
leakage, it’s requiring that you advertise to to world that you support this. I suspect
the disco is both redundant and counterproductive :)
/K
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
honestly I’m not entirely sure I like this. My naive implementation
would just stick a bunch of <item xmlns='jabber:iq:roster'
jid='nurse(a)example.com'/> in some sort of wrapper element into on
singleton roster node. No multiple items, not separate node for
groups. Just re-use the same <group/> children from jabber:iq:roster.
I reckon for most medium sized rosters the encryption overhead is the
bottle neck instead of the bandwidths constrains of one items vs
multiple items. 
2:01 p.m.
Hi all,
Chiming in to the "group vs. separate items" debate: my understanding of
the intended setup is that contacts are largely handled on the client
side, with the server being utilised only to synchronise the list
between devices (so we don't fetch the entire roster every time we
connect, but only listen for changes to the roster records).
If this is the case, wouldn't a separate item for each contact makes
more sense? When I add or update a record on one device, the other
devices will need to download (or be sent) only the changed records
rather than having to re-download the entire roster. Even in the case of
a multi-thousand item roster, a new client has to fetch that enormous
roster just once, and can subsequently fetch only the changed nodes.
The "downside" if we can call it one is that the server will know the
exact count of contacts each user has in their roster. But I'm not sure
this is something to be concerned about.
Best,
Badri
16 Jan
16 Jan
9:40 a.m.
Le jeudi 15 janvier 2026, 14:01:09 heure normale d’Europe centrale Badri a
écrit :
Hi all,
Chiming in to the "group vs. separate items" debate: my understanding of
the intended setup is that contacts are largely handled on the client
side, with the server being utilised only to synchronise the list
between devices (so we don't fetch the entire roster every time we
connect, but only listen for changes to the roster records).
If this is the case, wouldn't a separate item for each contact makes
more sense? When I add or update a record on one device, the other
devices will need to download (or be sent) only the changed records
rather than having to re-download the entire roster. Even in the case of
a multi-thousand item roster, a new client has to fetch that enormous
roster just once, and can subsequently fetch only the changed nodes.
The "downside" if we can call it one is that the server will know the
exact count of contacts each user has in their roster. But I'm not sure
this is something to be concerned about.
Best,
Badri
_______________________________________________
Standards mailing list -- standards(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org
Hi,
That's exactly that; having all in one pubsub item means having the whole
roster each time there is an update. Legacy bookmark was doing that, and
experience showed that it caused troubles.
The number of items issue is partially addressed in the protoXEP with the
<reserved/> element. I've also thought of allowing several <contact/>
elements
in a single item, but I'm afraid that it would over-complicate the management.
Maybe not.
Regarding groups, the issue I have with current roster group management is
that we can't simply rename a group: as it's not handled with IDs, we have to
modify all places where the group is handled. But I admit that this is less of
a problem in this case, as anyway the group is end-to-end encrypted, so only
the clients of the user know about it. Also, once we introduce IDs, we can add
descriptions and other metadata to groups (thinking about icons for instance).
But this is not major; we can remove it entirely if there is consensus on it,
and keep it the same way as in current roster's <item>.
Regarding the re-use of the whole roster's <item> in a single encrypted pubsub
item, beside the issue of updating mentioned above, the requirement here is to
not depend on the JID for identity (or anything linked to domain), which is
why an <identity> element is used. This is in anticipation of serverless,
moving from one server to another, and probably other features.
Anyway, I'm seeing this protoXEP as a starting point; I expect it to evolve
with feedback and experimentation. I would rather avoid 2 similar XEPs if we
can, but won't block it if people think it's a good way to find the best
solution.
Best,
Goffi
1:10 p.m.
On Fri, Jan 16, 2026 at 9:41 AM Goffi <goffi(a)goffi.org> wrote:
That's exactly that; having all in one pubsub item
means having the whole
roster each time there is an update. Legacy bookmark was doing that, and
experience showed that it caused troubles.
I’m expecting significantly fewer writes to the roster than on
bookmarks because we are not - for example - flipping autjoin flags.
To me the encryption here is the overhead. Especially OpenPGP has a
certain overhead per item. On initial connect I would much rather
decrypt one item and have the entire roster instead of n items.
And having one item also adds a bit of obscurity since the server
doesn’t see exactly how many users are in my roster, If i’m deleting
or adding a roster item and so forth.
Regarding groups, the issue I have with current roster
group management is
that we can't simply rename a group: as it's not handled with IDs, we have to
modify all places where the group is handled.
This might be obvious but the group renaming is also not an issue when
the entire roster is in one item because you write the entire thing
anyway.
Anyway, I'm seeing this protoXEP as a starting
point; I expect it to evolve
with feedback and experimentation. I would rather avoid 2 similar XEPs if we
can, but won't block it if people think it's a good way to find the best
solution.
I’m usually not blocking XEPs. This XEP can have a number. I just want
to make sure that if I ever publish my alternative approach I also get
a number. I mean yes experiments are fine; but I personally would like
to start my experiments with the one item approach.
cheers
Daniel
1:13 p.m.
On Fri, Jan 16, 2026 at 1:10 PM Daniel Gultsch <daniel(a)gultsch.de> wrote:
On Fri, Jan 16, 2026 at 9:41 AM Goffi <goffi(a)goffi.org> wrote:
Oh. And you are also avoiding weird bugs where various items of the
roster are encrypted with different key material. I mean obviously
nobody would attempt to do that on purpose but key material can change
after device migration and stuff.
cheers
Daniel
That's exactly that; having all in one pubsub
item means having the whole
roster each time there is an update. Legacy bookmark was doing that, and
experience showed that it caused troubles.
I’m expecting significantly fewer writes to the roster than on
bookmarks because we are not - for example - flipping autjoin flags.
To me the encryption here is the overhead. Especially OpenPGP has a
certain overhead per item. On initial connect I would much rather
decrypt one item and have the entire roster instead of n items.
And having one item also adds a bit of obscurity since the server
doesn’t see exactly how many users are in my roster, If i’m deleting
or adding a roster item and so forth.
3:03 p.m.
Le vendredi 16 janvier 2026, 13:10:44 heure normale d’Europe centrale Daniel
Gultsch a écrit :
I was also thinking about using groups outside (e.g. for pubsub permission),
but that use case is not possible anymore anyway with e2ee. So it may make
more sense indeed to remove the group node and stay with only the contacts
one.
On Fri, Jan 16, 2026 at 9:41 AM Goffi
<goffi(a)goffi.org> wrote:
With a single item, you are at risk of reaching size limit (either of the
stanza, or of the pubsub item), that alone is a good enough reason to no use a
single item IMO.
That's exactly that; having all in one pubsub
item means having the whole
roster each time there is an update. Legacy bookmark was doing that, and
experience showed that it caused troubles.
I’m expecting significantly fewer writes to the roster than on
bookmarks because we are not - for example - flipping autjoin flags.
To me the encryption here is the overhead. Especially OpenPGP has a
certain overhead per item. On initial connect I would much rather
decrypt one item and have the entire roster instead of n items. And having one item also adds a bit of obscurity since
the server
doesn’t see exactly how many users are in my roster, If i’m deleting
or adding a roster item and so forth.
Again, this is addressed partially in the XEP, with the <reserved> element.
We could also add the possibility to have several <contact> per pubsub item,
but we have to check that it worths the complication.
> Regarding groups, the issue I have with current
roster group management is
> that we can't simply rename a group: as it's not handled with IDs, we have
to
modify all
places where the group is handled.
This might be obvious but the group renaming is also not an issue when
the entire roster is in one item because you write the entire thing
anyway. I’m usually not blocking XEPs. This XEP can have a
number. I just want
to make sure that if I ever publish my alternative approach I also get
a number. I mean yes experiments are fine; but I personally would like
to start my experiments with the one item approach.
As I've said in my previous message, I would rather try to reach consensus to
avoid splitting implementations, but if we have a consensus on trying 2 ways
at the same time, I won't block it. Note that I'm not against your
propositions, as long as we end up with a sensible way to e2ee roster metadata
I'll be fine.
Thanks for your feedbacks.
Best,
Goffi
20 Jan
20 Jan
11:17 a.m.
Hi,
I'm going to make one last argument and then I think we will have exchanged
enough arguments for council to make a decision later today.
This is an experiment. We both agree that we need more implementational
experience. For now we don't really know if roster size or crypto overhead
and crypto operations will be be the bottle neck.
However if we don't know, the most sensible thing from my POV is to keep it
simple. Do the minimum viable thing. Take the existing roster, with its
existing features wrt groups and stick it into one encrypted item. Allow us
to reuse existing parsers. Make a drop in replacement for clear text
rosters.
Cheers
Daniel
11:49 a.m.
Le mardi 20 janvier 2026, 11:17:35 heure normale d’Europe centrale Daniel
Gultsch a écrit :
Hi,
I'm going to make one last argument and then I think we will have exchanged
enough arguments for council to make a decision later today.
This is an experiment. We both agree that we need more implementational
experience. For now we don't really know if roster size or crypto overhead
and crypto operations will be be the bottle neck.
But we know that stanza size and a single pubsub item size are limited. Is it
acceptable to have a limited size for roster?
However if we don't know, the most sensible thing
from my POV is to keep it
simple. Do the minimum viable thing. Take the existing roster, with its
existing features wrt groups and stick it into one encrypted item. Allow us
to reuse existing parsers. Make a drop in replacement for clear text
rosters.
Sure, and I did agree with your arguments on group: I plan to update the spec
to remove the dedicated group node to use the same thing as in roster (I just
don't do it know so the spec is not changing while council members are
checking it).
However, I'm not willing at this point to use the roster's <item> element
due
to the use of JID to identify the contact. The <identity> element has been
added in anticipation of using cryptographic fingerprint of whatever not tied
to a domain name to identify the contact (while JID still being usable, just
not mandatory and not the only way to identify the contact).
Another solution could be to abuse JID by doing something like
<somefingerprint>@<some_well_known_text> (e.g.;
`AABBCCDD112233@fingerprint`).
I actually think I have seen this used in a spec but I can't remember where.
Anyway, I find this option is not great, and we can't specify several
identities with that (to match a contact with JID and fingerprint).
The fact that I want to identify a contact without a domain-tied JID is to
prepare for serverless and facilitate server-moving, and I guess that it will
be useful for other things too.
Best,
Goffi
20 Feb
20 Feb
4:08 p.m.
Le mardi 20 janvier 2026, 11:49:09 heure normale d’Europe centrale Goffi a écrit
:
Sure, and I did agree with your arguments on group: I
plan to update the
spec
to remove the dedicated group node to use the same
thing as in roster (I
just
don't do it know so the spec is not changing while
council members are
checking it).
Actually the situation changed after council discussion. We are now talking of
not making the e2ee mandatory anymore, in other words, this specs could be
used to store extended metadata for any contacts, with a dedicated node for
e2ee version (so the client choose which data must be e2ee and which one can
be known from the server).
In this condition, I think that the separated group make sense for the
original reasons I did it:
- use an ID instead of the group name to identify it, so it can be renamed
without breaking anything based on groups (like access control for instance)
- extra metadata can be added to groups, like description, and probably other
things in future XEPs
So I would like feedback here, what do people think? Is it better to keep it
simple and just using a group with a name like we do in roster, or should we
improve it and have the possibility to add cleanly metadata?
I'm thinking that the latter is the best option now that group can be known by
server or other services, but I would like to have feedback.
Best,
Goffi
20 Jan
20 Jan
11:56 a.m.
New subject: Proposed XMPP Extension: End-to-End Encrypted Contacts Metadata
On 20 Jan 2026, at 10:17, Daniel Gultsch
<daniel(a)gultsch.de> wrote:
Hi,
I'm going to make one last argument and then I think we will have exchanged enough
arguments for council to make a decision later today.
This is an experiment. We both agree that we need more implementational experience. For
now we don't really know if roster size or crypto overhead and crypto operations will
be be the bottle neck.
I don’t think this is true. We do know that there are rosters in the wild that are large
enough to realistically be limited by pubsub item/stanza size limits. I don’t like
one-item-per-item at all, but I don’t think one-item-per-roster is viable.
/K
However if we don't know, the most sensible thing from my POV is to keep it simple.
Do the minimum viable thing. Take the existing roster, with its existing features wrt
groups and stick it into one encrypted item. Allow us to reuse existing parsers. Make a
drop in replacement for clear text rosters.
Cheers
Daniel
_______________________________________________
Standards mailing list -- standards(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org
12:12 p.m.
Le mardi 20 janvier 2026, 11:56:12 heure normale d’Europe centrale Kevin Smith
a écrit :
I don’t think this is true. We do know that there are
rosters in the wild
that are large enough to realistically be limited by pubsub
item/stanza size
limits. I don’t like one-item-per-item at all, but I don’t think one-item-per-
roster is viable.
/K
I was hesitating to allow several <contact> elements per roster as I've said
earlier in this thread. This has the advantage of decoupling the number of
pubsub items from the number of contacts, and letting the client decide how
many contacts to store in one item (which can be a full roster for small
ones). This, in addition to the <reserved> element, would totally blur the
number of contacts from the server.
Would this be an acceptable solution?
Best,
Goffi
12:20 p.m.
New subject: Proposed XMPP Extension: End-to-End Encrypted Contacts Metadata
On 20 Jan 2026, at 11:12, Goffi <goffi(a)goffi.org> wrote:
Le mardi 20 janvier 2026, 11:56:12 heure normale d’Europe centrale Kevin Smith
a écrit :
Sorry, I used my words carelessly. I don’t think one item per roster is viable, for large
rosters, so I think we should not do this. I don’t *like* one item per item, but I can’t
give a reason that it’s bad and that’s not a reason to not do it.
FWIW, we have existing precedent of one pubsub item per roster item in MDS, written by a
Daniel Gultsch :)
/K
I don’t think this is true. We do know that there
are rosters in the wild
that are large enough to realistically be limited by pubsub
item/stanza size
limits. I don’t like one-item-per-item at all, but I don’t think one-item-per-
roster is viable.
/K
I was hesitating to allow several <contact> elements per roster as I've said
earlier in this thread. This has the advantage of decoupling the number of
pubsub items from the number of contacts, and letting the client decide how
many contacts to store in one item (which can be a full roster for small
ones). This, in addition to the <reserved> element, would totally blur the
number of contacts from the server.
Would this be an acceptable solution? 
5:25 p.m.
This seems basically the same as bookmarks2. We have previously discussed
putting contacts in bookmarks2 and some have complained that they assume
everything in bookmarks2 is a MUC and so it's not allowed there.
In the interest of reducing duplication we've then discussed putting
extensions in the classic roster and then the client merges from both
sources as today.
Now if we want to move contacts into pubsub anyway it feels like what we
really want is boomarks3: bookmarks2 but with wording that makes it clear
that not everything in there is a MUC. This solves all the extended metadata
questions that have been coming up over recent years while also making both
things possible to encrypt with pubsub encryption methods as desired.
6:58 p.m.
On Tue, 20 Jan 2026 at 16:26, Stephen Paul Weber <singpolyma(a)singpolyma.net>
wrote:
Now if we want to move contacts into pubsub anyway it
feels like what we
really want is boomarks3: bookmarks2 but with wording that makes it clear
that not everything in there is a MUC. This solves all the extended
metadata
questions that have been coming up over recent years while also making
both
things possible to encrypt with pubsub encryption methods as desired.
This sounds like an awesome topic for summit!
7:45 p.m.
To be honest, I don't understand the "encrypted roster" discussion.
Even if the server does not see the roster at all, it is able to fully infer
which jids are part of a user's "roster" by just checking the PubSub
subscriptions and fetches of that user.
Isn't an "encrypted roster" implemented this way just a farce?
Or do I miss something important here?
-tmolitor
Am Dienstag, 20. Januar 2026, 18:58:28 CET schrieb Dan Caseley:
On Tue, 20 Jan 2026 at 16:26, Stephen Paul Weber
<singpolyma(a)singpolyma.net>
wrote:
Now if we want to move contacts into pubsub
anyway it feels like what we
really want is boomarks3: bookmarks2 but with wording that makes it clear
that not everything in there is a MUC. This solves all the extended
metadata
questions that have been coming up over recent years while also making
both
things possible to encrypt with pubsub encryption methods as desired.
This sounds like an awesome topic for summit!
8 p.m.
To be honest, I don't understand the
"encrypted roster" discussion.
Even if the server does not see the roster at all, it is able to fully infer
which jids are part of a user's "roster"
Absolutely. For most clients/apps developed as they are today this is not
useful and would not be used. But if you were making a specially handled
client that eg did not send or request presence from anyone, did sealed
sender / sealed recipient with a TBD onion routing XEP, and other things
then this could be a useful building block to still allow syncing contacts
between multiple such apps instead of having them just local.
We may be going cart-before-the-horse here but OTOH having a building block
isn't bad.
8:28 p.m.
Le mardi 20 janvier 2026, 19:45:35 heure normale d’Europe centrale Thilo
Molitor a écrit :
To be honest, I don't understand the
"encrypted roster" discussion.
Even if the server does not see the roster at all, it is able to fully infer
which jids are part of a user's "roster" by just checking the PubSub
subscriptions and fetches of that user.
Isn't an "encrypted roster" implemented this way just a farce?
Or do I miss something important here?
-tmolitor
The JID is not visible, it's a random ID in the pubsub items, and the fetches
are done whenever client want to sync. There is a single node to subscribe,
you can't get any information from that, beside a very approximate size of the
roster, and the <reserved> element is there to make it muddy.
The server can know who you are communicating with by checking "from" and
"to"
from message (until we have something like sealed sender), or checking PEP
requests (for OMEMO for instance), but the goal here is to hide the sensitive
metadata (name, and groups, possibly other things).
This is a first step toward metadata reduction. The server can vaguely guess
the relations of the entity, but it has less information than before. Other
steps such as sealed sender will be discussed (notably at the incoming
summit).
Best,
Goffi
21 Jan
21 Jan
5:57 p.m.
On 1/20/26 12:28 PM, Goffi wrote:
Le mardi 20 janvier 2026, 19:45:35 heure normale
d’Europe centrale Thilo
Molitor a écrit :
From the perspective of a privacy-respecting server administrator, I
would say there are benefits in not knowing the "social graph" (e.g.,
there is precedent for governmental authorities to request the roster
for JIDs of interest). There are also costs (e.g., in the past I have
asked users who've lost their password to verify JIDs in the roster as a
way to verify JID "ownership"). However, it seems to me that the
benefits outweigh the costs.
Peter
To be honest, I don't understand the
"encrypted roster" discussion.
Even if the server does not see the roster at all, it is able to fully infer
which jids are part of a user's "roster" by just checking the PubSub
subscriptions and fetches of that user.
Isn't an "encrypted roster" implemented this way just a farce?
Or do I miss something important here?
-tmolitor
The JID is not visible, it's a random ID in the pubsub items, and the fetches
are done whenever client want to sync. There is a single node to subscribe,
you can't get any information from that, beside a very approximate size of the
roster, and the <reserved> element is there to make it muddy.
The server can know who you are communicating with by checking "from" and
"to"
from message (until we have something like sealed sender), or checking PEP
requests (for OMEMO for instance), but the goal here is to hide the sensitive
metadata (name, and groups, possibly other things).
This is a first step toward metadata reduction. The server can vaguely guess
the relations of the entity, but it has less information than before. 
20 Jan
20 Jan
7:34 p.m.
On 2026/01/20, Stephen Paul Weber wrote:
Now if we want to move contacts into pubsub anyway it
feels like what we
really want is boomarks3: bookmarks2 but with wording that makes it clear
that not everything in there is a MUC.
Maybe `autojoin` can be moved as an extension if that's the case, so we
can finally have bookmarks be a dumb list of things. /pet-peeve
21 Jan
21 Jan
7:20 p.m.
On Tue, 20 Jan 2026 at 16:26, Stephen Paul Weber <singpolyma(a)singpolyma.net>
wrote:
Now if we want to move contacts into pubsub anyway it
feels like what we
really want is boomarks3:
Bookmarks 3: The Revenge Of PEP?
(From XEP-0402: This specification was originally entitled "Bookmarks 2:
This Time It's Serious". Any implication of a sense of humour has been
removed with the change in title.)
Bookmarks 2 has to only store chatrooms because it's built around the same
syntax as Bookmarks 1.
There's no reason not to put all contact-stuff into a single pubsub node -
after all, not so long ago we were looking to put it all into the roster.
Dave.
25 Jan
25 Jan
2:49 p.m.
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 <daniel(a)gultsch.de> 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 -- standards(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org
27 Jan
27 Jan
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
4:32 p.m.
On Tue, 27 Jan 2026 at 15:19, Goffi <goffi(a)goffi.org> wrote:
the same
data if some encryption isn't named as a MUST/SHOULD, and there's
no metadata layer to give the client clues.
- 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.
My concern is that 2 client implementations might be unable to operate on
4:35 p.m.
New subject: Proposed XMPP Extension: End-to-End Encrypted Contacts Metadata
On 27 Jan 2026, at 15:18, Goffi <goffi(a)goffi.org> wrote:
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.
I think that, pretty much, either you have it specified how agility works, or you don’t
have agility. Possibly that doesn’t have to happen initially, but until you have agility
specced, you’re locked in.
/K
10
days inactive
46
days old
25 comments
10 participants
participants (10)
-
Badri -
Dan Caseley -
Daniel Gultsch -
Dave Cridland -
Goffi -
Kevin Smith -
Maxime Buquet -
Peter Saint-Andre -
Stephen Paul Weber -
Thilo Molitor