Le mardi 20 janvier 2026, 11:17:35 heure normale d’Europe centrale Daniel
Gultsch a écrit :
Hi,
I'm going to make one last argument and then I think we will have exchanged
enough arguments for council to make a decision later today.
This is an experiment. We both agree that we need more implementational
experience. For now we don't really know if roster size or crypto overhead
and crypto operations will be be the bottle neck.
But we know that stanza size and a single pubsub item size are limited. Is it
acceptable to have a limited size for roster?
However if we don't know, the most sensible thing
from my POV is to keep it
simple. Do the minimum viable thing. Take the existing roster, with its
existing features wrt groups and stick it into one encrypted item. Allow us
to reuse existing parsers. Make a drop in replacement for clear text
rosters.
Sure, and I did agree with your arguments on group: I plan to update the spec
to remove the dedicated group node to use the same thing as in roster (I just
don't do it know so the spec is not changing while council members are
checking it).
However, I'm not willing at this point to use the roster's <item> element
due
to the use of JID to identify the contact. The <identity> element has been
added in anticipation of using cryptographic fingerprint of whatever not tied
to a domain name to identify the contact (while JID still being usable, just
not mandatory and not the only way to identify the contact).
Another solution could be to abuse JID by doing something like
<somefingerprint>@<some_well_known_text> (e.g.;
`AABBCCDD112233@fingerprint`).
I actually think I have seen this used in a spec but I can't remember where.
Anyway, I find this option is not great, and we can't specify several
identities with that (to match a contact with JID and fingerprint).
The fact that I want to identify a contact without a domain-tied JID is to
prepare for serverless and facilitate server-moving, and I guess that it will
be useful for other things too.
Best,
Goffi