Re: Proposed XMPP Extension: End-to-End Encrypted Contacts Metadata

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 <[email protected]> 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

_______________________________________________
Standards mailing list -- [email protected]
To unsubscribe send an email to [email protected]

-----BEGIN PGP SIGNATURE-----

iQEzBAABCgAdFiEEsNZvWyEnjW9SVudbKqmcu6xuKwwFAmlqRS0ACgkQKqmcu6xu
Kwz3Gwf/Y1aqYUX6O2Wa2DJJVqb3Y84bLxF7txG8kn1dMvS/i75wyFvMNHqGPKt3
+D9veoDuQ/D1zTpXLt564HAPbu02188e5KaXJuTSe3fjcSRYmv0Gz3TX8g9haBCD
PJayvPNkANhAm5zgBnaYful1I/aD+DxwA1fyBJ//RKYQ3uImu0j8IlnuZ2bj0pBf
e/5tDVTMjUhzKg/Ii4989Tise3MD26wq0cGhwLdd/nPOxSguxWP9iaEVKnSZrOwL
FTioGyUXh3NCvXb1FODblOqp4NLsjpPyyLQKJUJVOBvNSAMTx+N/2GDOUGBCsEq2
7y76hqn9fCDps8ieJaK6rTIiLHoFLg==
=YbZH
-----END PGP SIGNATURE-----