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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Standards mailing list -- [email protected] To unsubscribe send an email to [email protected]
