27 Jan
2026
27 Jan
'26
4:32 p.m.
On Tue, 27 Jan 2026 at 15:19, Goffi <goffi(a)goffi.org> wrote:
the same
data if some encryption isn't named as a MUST/SHOULD, and there's
no metadata layer to give the client clues.
- 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