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