Re: [Standards] Offline Feature Negotiation and Device Lists

[Ralph Meijer]

On 17-02-2020 14:58, Matthew Wild wrote:

[..]

> > 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 don't think there's a way that all cases can be handled perfectly.

I want to expand my original use case with video calls. Our development 
of calls was in stages: first voice calls, later video. That means that 
at a certain point, there'd be three types of clients: ones that didn't 
support calls, ones that supported voice calls, and ones that supported 
voice and video calls. It is very useful to users to know what they can 
do in this situation.


Even if your account would signal that there is a registered device that 
can handle calls, a call attempt might still fail for all kinds of 
reasons. That's fine. Knowing that there's no such potential device, 
however, is useful to know, especially in the case where they are not 
online. A client could choose to not show a button to initiate a call.


Similarly, if your contact has two devices: one capable of voice calls, 
one capable of video calls, you can offer the user to initiate a video 
call. Both would ring, and video would simply fail to be negotiated. 
This is fine, as the contact might also have chosen to only respond with 
voice, even if offered video.


In short: service discovery is a way to better inform the other party of 
possible interaction patterns. It is not a guarantee that they actually 
succeed.


--
ralphm
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Offline Feature Negotiation and Device Lists

[Matthew Wild]

On Mon, 17 Feb 2020 at 13:25, Dave Cridland  wrote:
> On Mon, 17 Feb 2020 at 12:05, Matthew Wild  wrote:
>>
>> On Sun, 16 Feb 2020 at 12:00, Dave Cridland  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
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Offline Feature Negotiation and Device Lists

[Matthew Wild]

On Mon, 17 Feb 2020 at 13:24, Ralph Meijer  wrote:
>
>
>
> On 17-02-2020 13:44, Matthew Wild wrote:
> > On Mon, 17 Feb 2020 at 12:14, Ralph Meijer  wrote:
> >>
> >>
> >>
> >> On 17-02-2020 13:04, Matthew Wild wrote:
> >>> 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.
> >>
> >> Ok, concrete use case from my time at VEON: calling.
> >
> > I almost included this case in my initial email, but I see it as
> > pretty much the same as the encryption one.
> >
> > Just because I signed into my account once with a client that supports
> > receiving calls, doesn't mean I necessarily am available to receive
> > calls on my account.
> >
> > As a personal example, I work from home most of the time, and my
> > primary XMPP communication is through my laptop. My phone is very
> > often in flight mode or flat on days when I don't leave the house. My
> > primary client is poezio running in tmux over ssh. It's not getting
> > Jingle A/V any time soon.
> >
> > In my case I don't want people to think that they can just call me
> > over Jingle on my work-from-home days because I signed in with a
> > Jingle A/V client a few days ago.
>
> The way things currently work, if your client happens to be online at
> any given time during your work-from-home days, it already exposes this
> capability and other clients can show a widget to call you.

And that would of course be fine. If my phone is charged, turned on
and on the network, I'd expect it to be able to receive calls of
course.

My problem is that when my phone is not online, I don't want that
capability being "remembered" on my account and misleading other
clients who assume I therefore always have a Jingle-capable device
around.

Regards,
Matthew
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Offline Feature Negotiation and Device Lists

[Dave Cridland]

On Mon, 17 Feb 2020 at 12:05, Matthew Wild  wrote:

> On Sun, 16 Feb 2020 at 12:00, Dave Cridland  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".


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

Dave.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Offline Feature Negotiation and Device Lists

[Ralph Meijer]

On 17-02-2020 13:44, Matthew Wild wrote:

On Mon, 17 Feb 2020 at 12:14, Ralph Meijer  wrote:




On 17-02-2020 13:04, Matthew Wild wrote:

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.


Ok, concrete use case from my time at VEON: calling.


I almost included this case in my initial email, but I see it as
pretty much the same as the encryption one.

Just because I signed into my account once with a client that supports
receiving calls, doesn't mean I necessarily am available to receive
calls on my account.

As a personal example, I work from home most of the time, and my
primary XMPP communication is through my laptop. My phone is very
often in flight mode or flat on days when I don't leave the house. My
primary client is poezio running in tmux over ssh. It's not getting
Jingle A/V any time soon.

In my case I don't want people to think that they can just call me
over Jingle on my work-from-home days because I signed in with a
Jingle A/V client a few days ago.


The way things currently work, if your client happens to be online at 
any given time during your work-from-home days, it already exposes this 
capability and other clients can show a widget to call you.


So I think this basically means you'd want your mobile client to not 
advertise the capabilities related to calling. CAPS was specifically 
designed such that you can relay changes in capabilities, and this seems 
one of those things you should be able to toggle. Your problem seems 
orthogonal to the things being discussed here.


--
ralphm
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Offline Feature Negotiation and Device Lists

[Matthew Wild]

On Mon, 17 Feb 2020 at 12:14, Ralph Meijer  wrote:
>
>
>
> On 17-02-2020 13:04, Matthew Wild wrote:
> > 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.
>
> Ok, concrete use case from my time at VEON: calling.

I almost included this case in my initial email, but I see it as
pretty much the same as the encryption one.

Just because I signed into my account once with a client that supports
receiving calls, doesn't mean I necessarily am available to receive
calls on my account.

As a personal example, I work from home most of the time, and my
primary XMPP communication is through my laptop. My phone is very
often in flight mode or flat on days when I don't leave the house. My
primary client is poezio running in tmux over ssh. It's not getting
Jingle A/V any time soon.

In my case I don't want people to think that they can just call me
over Jingle on my work-from-home days because I signed in with a
Jingle A/V client a few days ago.

Regards,
Matthew
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Offline Feature Negotiation and Device Lists

[Ralph Meijer]

On 17-02-2020 13:04, Matthew Wild wrote:

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.


Ok, concrete use case from my time at VEON: calling.

In the situation where most/all of your "known devices" are mobile, the 
likelihood of them being offline at any given time approaches 1. If only 
because the increasingly strict battery-saving measures in mobile 
operating systems.


I would still like to know if there's at least one device that can be 
waken up to receive an attempt to call. And only then send a special 
push notification, containing a compressed session initiation iq, to 
simultaneously wake up a device, have the receiving app prepare for 
taking the call, presenting a user interface and waiting for the user to 
click 'accept call' or 'reject call', while in the meantime a connection 
to the XMPP server is being established.


Yes, potentially you could use information cached from previous times 
the recipient's clients were online, but in practice this is quite 
cumbersome.


--
ralphm
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Offline Feature Negotiation and Device Lists

[Matthew Wild]

On Sun, 16 Feb 2020 at 12:00, Dave Cridland  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
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Offline Feature Negotiation and Device Lists

[Philipp Hörist]

Hi,

Am Mo., 17. Feb. 2020 um 12:12 Uhr schrieb Ralph Meijer :

>
> One thing I'm concerned about in general is what happens if I start
> sending presence to my contacts. I would get a PEP notification for each
> of my contacts with their capabilities. Bandwidth-wise having hashes
> here helps, but still it is a lot of traffic. Especially for mobile
> uses, it might be better to retrieve this information incrementally,
> through regular disco or perhaps a new IQ-get exchange for CAPS hash sets.
>

Yes im also concerned about this. Putting stuff into PEP and using +notify
is convenient.

But it clearly does not scale well at all.

You might be ok for 20-30 contacts but not for 300

Just from the top of my head

UserAvatar
UserMood
UserTune
UserNick
UserLocation
UserActivity
OMEMO
OpenPGP

I'm sure there are even more.

This will soon reach an amount where a client simply can't implement these
XEPs because of performance reasons.
At some point we should make this scaleable.

Regards
Philipp
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Offline Feature Negotiation and Device Lists

[Ralph Meijer]

On 17-02-2020 09:57, Dave Cridland wrote:
On Sun, 16 Feb 2020 at 12:49, Ralph Meijer > wrote:


> Have you considered special disco nodes on the account that get
> synthesized by the server based on the disco information from
> registered devices?

I wondered about that. We could have a pair of disco nodes as well, yes.

> Do you think there's value in the ability to subscribe to this
> information via PEP?

I think there's severe disadvantages in having the information only 
available via PEP. But PEP remains our best choice for data that needs 
to be public and disseminated around a user's contacts.


The trouble is that PEP is also limited in the case of anything but a 
two-way presence subscription.


But using PEP for entity caps (XEP-0390-in-PEP, in effect) seems like a 
useful compromise, with the actual disco being held against the user's 
account.


My thinking here was that you'd have two nodes you can access both via 
disco as well as publish-subscribe. Notifications for the latter would 
be constructed by the server (as only publisher), and an entity could 
subscribe either directly (e.g. another server), or via +notify (other 
clients). One node for "all registered devices support these things", 
one for "at least on registered device supports these things".


A two-way presence subscription would not be needed if the nodes have an 
open access model. I haven't really considered in what cases having 
either an open access model, or not being able to use +notify, would be 
considered a downside.


I'm not sure about the need for CAPS hashes for this, next to the full 
disco#info in the payload of a pubsub item. If so, we probably should 
have two parallel nodes for subscribing (explicitly or implicitly) to 
just the hashes.


One thing I'm concerned about in general is what happens if I start 
sending presence to my contacts. I would get a PEP notification for each 
of my contacts with their capabilities. Bandwidth-wise having hashes 
here helps, but still it is a lot of traffic. Especially for mobile 
uses, it might be better to retrieve this information incrementally, 
through regular disco or perhaps a new IQ-get exchange for CAPS hash sets.


Crazy idea: a sibling element to the MAM result messages when doing an 
inbox request, with the CAPS hash set for the entry's other party.


--
ralphm
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Offline Feature Negotiation and Device Lists

[Dave Cridland]

On Sun, 16 Feb 2020 at 12:49, Ralph Meijer  wrote:

> Hace you considered special disco nodes on the account that get
> synthesized by the server based on the disco information from registered
> devices?
>

I wondered about that. We could have a pair of disco nodes as well, yes.


> Do you think there's value in the ability to subscribe to this information
> via PEP?
>

I think there's severe disadvantages in having the information only
available via PEP. But PEP remains our best choice for data that needs to
be public and disseminated around a user's contacts.

The trouble is that PEP is also limited in the case of anything but a
two-way presence subscription.

But using PEP for entity caps (XEP-0390-in-PEP, in effect) seems like a
useful compromise, with the actual disco being held against the user's
account.


>
> --
> ralphm
> --
> *From:* Dave Cridland 
> *Sent:* Sunday, February 16, 2020 12:58
> *To:* XMPP Standards
> *Subject:* [Standards] Offline Feature Negotiation and Device Lists
>
> Hiya,
>
> We talked at the Summit about wanting to do device lists and things, but
> we didn't actually get that far. That's fine, of course, we can't discuss
> everything.
>
> But perhaps we can discuss what we want out of such a thing now.
>
> I'm thinking there's three potential "consumers" for such a
> feature-cluster:
>
> 1) Other Clients
>
> You have multiple devices, running potentially multiple clients. They may
> wish to know about each other on a long-term basis.
>
> 2) Your Home Server
>
> Your Home Server might need to know about which clients you're actively
> using in order to offer generalised services and things.
>
> 3) Other Entities
>
> Other entities may wish to know what features are, in general, supported
> across all or some of your devices. They may only need to know aggregations
> of this, or may need to know more details in some cases.
>
> I think - and may be wrong - that (1) and (2) are very closely related
> here. They'd always be non-aggregated, and for things like authentication
> this would be managed by the clients but executed upon by the server.
>
> (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 think we build (1) and (2) out of a series of private PEP nodes, with
> one item per client. We identify a client by UUIDv4 generated by the
> client. We would have a PEP node containing XEP-0030 disco#info, which
> would then synthesize the information for (3).
>
> I think we build (3) out of that information as two (or maybe more) PEP
> nodes. A tricky challenge is that clients that don't understand (1)/(2)
> won't be aggregated properly. I suggest, therefore, that use of clients
> that don't support (1)/(2) causes some kind of fallback mechanism in (3) -
> perhaps we assume it's an unknown client and move anything unsupported to
> "some".
>
> I think entity caps and end-to-end XEP-0030 will drastically reduce as a
> result of this, by the way.
>
> Does all this sound like a starting point?
>
> Dave
>
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Offline Feature Negotiation and Device Lists

[Ralph Meijer]

Hace you considered special disco nodes on the account that get synthesized by 
the server based on the disco information from registered devices? Do you think 
there's value in the ability to subscribe to this information via PEP?

--
ralphm

From: Dave Cridland 
Sent: Sunday, February 16, 2020 12:58
To: XMPP Standards
Subject: [Standards] Offline Feature Negotiation and Device Lists

> Hiya,
>
> We talked at the Summit about wanting to do device lists and things, but we 
> didn't actually get that far. That's fine, of course, we can't discuss 
> everything.
>
> But perhaps we can discuss what we want out of such a thing now.
>
> I'm thinking there's three potential "consumers" for such a feature-cluster:
>
> 1) Other Clients
>
> You have multiple devices, running potentially multiple clients. They may 
> wish to know about each other on a long-term basis.
>
> 2) Your Home Server
>
> Your Home Server might need to know about which clients you're actively using 
> in order to offer generalised services and things.
>
> 3) Other Entities
>
> Other entities may wish to know what features are, in general, supported 
> across all or some of your devices. They may only need to know aggregations 
> of this, or may need to know more details in some cases.
>
> I think - and may be wrong - that (1) and (2) are very closely related here. 
> They'd always be non-aggregated, and for things like authentication this 
> would be managed by the clients but executed upon by the server.
>
> (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 think we build (1) and (2) out of a series of private PEP nodes, with one 
> item per client. We identify a client by UUIDv4 generated by the client. We 
> would have a PEP node containing XEP-0030 disco#info, which would then 
> synthesize the information for (3).
>
> I think we build (3) out of that information as two (or maybe more) PEP 
> nodes. A tricky challenge is that clients that don't understand (1)/(2) won't 
> be aggregated properly. I suggest, therefore, that use of clients that don't 
> support (1)/(2) causes some kind of fallback mechanism in (3) - perhaps we 
> assume it's an unknown client and move anything unsupported to "some".
>
> I think entity caps and end-to-end XEP-0030 will drastically reduce as a 
> result of this, by the way.
>
> Does all this sound like a starting point?
>
> Dave
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___