[Standards] Offline Feature Negotiation and Device Lists
mwild1 at gmail.com
Mon Feb 17 13:51:08 UTC 2020
On Mon, 17 Feb 2020 at 13:24, Ralph Meijer <ralphm at ik.nu> wrote:
> 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
> >>> 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
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
More information about the Standards