15 Jan
2026
15 Jan
'26
10: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
10: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
11:54 a.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. 
1: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
8: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
12: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
12: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.
2: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
10: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
10: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
10: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
11:12 a.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
11:20 a.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? 
4: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.
5: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!
6: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!
7 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.
7: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
6: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
1
days inactive
6
days old
18 comments
8 participants
participants (8)
-
Badri -
Dan Caseley -
Daniel Gultsch -
Goffi -
Kevin Smith -
Maxime Buquet -
Stephen Paul Weber -
Thilo Molitor