[Standards] Offline Feature Negotiation and Device Lists

Matthew Wild mwild1 at gmail.com
Mon Feb 17 12:04:32 UTC 2020


On Sun, 16 Feb 2020 at 12:00, Dave Cridland <dave at cridland.net> wrote:
> (3) is different; I'm unconvinced that we ever want to allow a third party to know the details of what clients exist (though ClientInitKeys will reveal that to some degree). But we do want to indicate if, for example, "all" our clients support encryption, or only "some". We might even want to indicate meta-detail - all our clients may support encryption, but we might actually prefer things not to be encrypted by default - but perhaps that's outside the scope here.

I am extremely unconvinced that this is a problem we need to solve,
or: if there is a problem I don't think this is the right way to solve
it.

At first glance it seems obvious - there are problems with using
entity caps in a world where being disconnected is increasingly a
normal thing for an XMPP client. So we need to make persistent
capabilities, right?

One problems with the approach is that devices come and go all the
time - so any protocol needs to deal with the capabilities changing
between time of check and time of $action anyway.

>From what I've seen thrown around so far, I have yet to see an actual
case for how this information could be used that isn't solved (usually
better) using a fix specific for the protocol in question. I feel that
encryption for example should be a per-account toggle - and if I
temporarily sign in with a client that doesn't support encryption,
that's not enough of a reason for everyone to stop sending me
encrypted messages. (and yes: all this comes with obvious security
considerations, whatever method we use to determine whether to
encrypt).

I really don't want to just design an account capabilities system
without some real concrete use-cases that demonstrate it's our best
option.

Regards,
Matthew


More information about the Standards mailing list