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

On Fri, Jan 16, 2026 at 9:41 AM Goffi <goffi@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

Le vendredi 16 janvier 2026, 13:10:44 heure normale d’Europe centrale Daniel Gultsch a écrit :

On Fri, Jan 16, 2026 at 9:41 AM Goffi <goffi@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.

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.

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 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.

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

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

On 20 Jan 2026, at 10:17, Daniel Gultsch <daniel@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@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org

On 20 Jan 2026, at 11:12, Goffi <goffi@goffi.org> wrote:

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?

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

On Tue, 20 Jan 2026 at 16:26, Stephen Paul Weber <singpolyma@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!

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.

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 :

...

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.

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

On Tue, 20 Jan 2026 at 16:26, Stephen Paul Weber <singpolyma@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.

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

On 27 Jan 2026, at 15:18, Goffi <goffi@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