On Tue, 27 Jan 2026 at 15:19, Goffi <[email protected]> wrote:
> > - I'm a bit uncomfortable with the text about encryption. "Both node > items > > MUST be end-to-end encrypted", but then goes on to loosely recommend one > > method, and add a MAY that something that isn't a MUST or SHOULD might > > change in the future. Does this need either one MUST/SHOULD mechanism to > > enable compatible implementations, or a metadata layer to inform the > client > > of the mechanism? > > The contacts MUST be e2e encrypted, it the raison d'être of this > specification. > The rest just open the door to a future better encryption method, so we > don't > stay forever blocked on OX for pubsub. We have namespaces to deal with > that, I > don't see we need much more. Maybe the formulation can be improved, but > the > idea is to say that e2ee is mandatory, and that we have a method right now > the > must be used as long as there is no better alternative, and the door is > open > for better algorithm is any in the future. > > My concern is that 2 client implementations might be unable to operate on the same data if some encryption isn't named as a MUST/SHOULD, and there's no metadata layer to give the client clues.
_______________________________________________ Standards mailing list -- [email protected] To unsubscribe send an email to [email protected]
