[Standards] Offline Feature Negotiation and Device Lists

Dave Cridland dave at cridland.net
Mon Feb 17 13:25:26 UTC 2020

On Mon, 17 Feb 2020 at 12:05, Matthew Wild <mwild1 at gmail.com> wrote:

> 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).
OK. We have three possible states for a capability:

"always" - the feature is always supported by all clients you use.

"sometimes" - the feature is supported by some of the clients you use.

"never" - the feature is supported by none of the clients you use.

We then also have an additional dimension for what we mean by "a client you
use" - did you explicitly register it, or not? Let's call clients you don't
explicitly register "ad-hoc", and note that right now, all clients are

For encryption, and indeed anything else I can think of, bringing a client
online that you don't explicitly register should clearly not cause a
downgrade from "always" to "sometimes". But explicitly registering one
probably should.

For calling, saying that you "sometimes" support offline calling when an
ad-hoc client supporting calling pops up is going to be tricky, but I don't
think that it's clear-cut that you'd describe this as "never" either. So
either we include it in "sometimes", but with a timeout perhaps, or else we
include it in a new category of "ad-hoc".

> 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.

Oh, I think it's our only option, and it's already upon us - we have the
situation right now with things like Push, OMEMO, and more, where we have a
partial broken client registration.

Calling and others also clearly need this.

Indeed, any case where we want to use some form of negotiated end-to-end
principle but the ends are not concurrently online needs this.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20200217/014ccd93/attachment.html>

More information about the Standards mailing list