[Standards] Offline Feature Negotiation and Device Lists
ralphm at ik.nu
Mon Feb 17 13:23:22 UTC 2020
On 17-02-2020 13:44, Matthew Wild wrote:
> On Mon, 17 Feb 2020 at 12:14, Ralph Meijer <ralphm at ik.nu> 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
>> 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.
More information about the Standards