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