XSF Discussion - 2019-07-13

Daniel: issues with sending XEP-0357 to include body or potentially the whole stanzas: privacy and size limits

ralphm: if this is in response to my tweet I was mostly referring to the paragraph following 'business rules. Not necessarily the entire section.

For VEON we used pushes for voice calling, too, and found that including all the information, including candidates and such, would not fit in platform notifications

Communicating what triggered the push is complicated ™ and I don't have a good solution for that

So we employed a scheme to compress the stanzas with a precalculated dictionary

ralphm: I think the idea in sending the entire stanza is that the app server can make the decision

And either just make the judgment call between priority or not.

Sure, for calling this is also important as it allows for much quicker call setup.

Or do something else like the compression thing

I.e. you spare some expensive round-trips, and when it comes in you have to wait for the user to look at the incoming call, while in the background you establish the connection to the server.

Not sure if the same is really an issue for group chats

That's less time critical.

In a federated environment the privacy concerns are probably the most predominant ones. But it also _mostly_ concerns iOS so I'm not super involved into what the community currently considers best practices

> I.e. you spare some expensive round-trips, and when it comes in you have to wait for the user to look at the incoming call, while in the background you establish the connection to the server. Those are good points though that I'm sure the people involved in this haven't considered yet but are definitely worth considering for a revamp of 357

Maybe it is good enough for a client to just be woken by its server (implementing push) and then retrieve MAM history.

(for group chat, not calls)

Note that services like Slack don't guarantee immediate notification, but rather in the few-seconds range.

But sure you only have limited time to do something in response to a notification, so you either need some body, or a fast reconnect.

Yes push is complicated. That's why during the sprint we ultimately came to the conclusion that it is best to give the app server all the information so the app server can make those decisions. Because notification settings might also be client and platform depended. So either you need a way to upload your rules to your own server or to your app server

I'm not talking about local system notifications, those are not really related

I was told on iOS they kinda are

I.e. your app can definitely get push notifications without the user seeing any notification.

If you want to use high priority

But yeah that's also why I'm personally not very familiar with the matter. On Android I just high priority push all the time and let the app figure it out

But I was told on iOS that's not that easy

Requiring high priority notifications for MUC seems like an edge case.

I.e. if messages in a group are so highly time sensitive, maybe you are using the wrong medium.

And yeah, iOS is picky. Android has been tightening stuff down, too.

Now we're slightly on the topic, how is that notification channel separation between one-on-one, mentions, other group messages coming along? 😋

It's still on my todo list.

😃

> I.e. if messages in a group are so highly time sensitive, maybe you are using the wrong medium. I see no basis to assume group messages being less time sensitive than 1:1. I think people totally expect being able to use private IM groups for communication about appointments and stuff just like they do in 1:1 chat.

I wasn't comparing 1:1 to group, rather messages vs. calls.

For calls you preferably get all the candidiates and other info as fast as possible from the callee via Push, so that your app can already start setting up, figure out its own candidates, etc., notify the user, present a calling screen, without having to reestablish the XMPP connection. While the slow human reacts, there is plenty of time to set up that connection, retrieve avatars or other information, and possibly update the screen. When the slow human has finally accepted the call, connecting is noticibly much faster.

I'd say for text messages, the relative need for speed is in the several seconds range, so might choose to go with the push-just-wakes-up scenario.

Sometimes good enough is good enough.

Holger: ^

Ah, right.