16 Jan
2026
16 Jan
'26
8:40 a.m.
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 -- standards(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org
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