[Standards] Offline Feature Negotiation and Device Lists

Matthew Wild mwild1 at gmail.com
Mon Feb 17 13:58:14 UTC 2020


On Mon, 17 Feb 2020 at 13:25, Dave Cridland <dave at cridland.net> wrote:
> 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 ad-hoc.
>
> 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".

The model you lay out here makes sense, for sure, but still feels like
a solution looking for a problem. I get that we *have* problems, but I
repeat that I'm unconvinced that the solution involves knowing what
features past/present clients support.

Your point about calling being "tricky" is exactly my point. We have
this information ("some of the recipient's devices support calling,
but they aren't currently online"). We still have to handle the case
where the devices supporting the required capability have 1) gone
permanently offline, never to return  2) are currently out of range,
turned off for the day, etc.

If we have to handle the case where there is no available device to
handle the feature, what is this protocol to be used for?

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

Whether you think it's our only option is precisely not my point.

Also I 100% (and more) agree that we need device tracking/management
in the server. I just disagree that something resembling "entity
capabilities, but on the account" is as useful in the real world as it
sounds from a protocol perspective.

Regards,
Matthew


More information about the Standards mailing list