On 15 Jan 2026, at 10:52, Daniel Gultsch <[email protected]> wrote: > > Hi, > > On Thu, Jan 15, 2026 at 11:37 AM Daniel Gultsch <[email protected]> wrote: > >> 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='[email protected]'/> 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.
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 _______________________________________________ Standards mailing list -- [email protected] To unsubscribe send an email to [email protected]
