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