Re: Proposed XMPP Extension: End-to-End Encrypted Contacts Metadata

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]