15 Jan
2026
15 Jan
'26
11:54 a.m.
On 15 Jan 2026, at 10:52, Daniel Gultsch <daniel(a)gultsch.de> wrote:
Hi,
On Thu, Jan 15, 2026 at 11:37 AM Daniel Gultsch <daniel(a)gultsch.de> wrote:
For ’normal’ rosters, I think the many-items thing is an irritation rather than helpful.
For a stpeter roster, though, you could start running into issues with size limits trying
to put everything into a single item, I think? Of course, if you *do* have a
multi-thousand item roster, one item per roster item is also unfortunate, so I suspect
neither of these approaches is truly ideal.
On a different note - I’m curious why, in a spec that’s concerned with reducing metadata
leakage, it’s requiring that you advertise to to world that you support this. I suspect
the disco is both redundant and counterproductive :)
/K
Title: End-to-End Encrypted Contacts Metadata
Abstract:
This specification describes how to encrypt contacts metadata to
minimize server exposure.
URL: https://xmpp.org/extensions/inbox/contacts-e2e.html
honestly I’m not entirely sure I like this. My naive implementation
would just stick a bunch of <item xmlns='jabber:iq:roster'
jid='nurse(a)example.com'/> in some sort of wrapper element into on
singleton roster node. No multiple items, not separate node for
groups. Just re-use the same <group/> children from jabber:iq:roster.
I reckon for most medium sized rosters the encryption overhead is the
bottle neck instead of the bandwidths constrains of one items vs
multiple items.