Daniel: issues with sending XEP-0357 to include body or potentially the whole stanzas: privacy and size limits
Daniel
ralphm: if this is in response to my tweet I was mostly referring to the paragraph following 'business rules. Not necessarily the entire section.
ralphm
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
Daniel
Communicating what triggered the push is complicated ™ and I don't have a good solution for that
ralphm
So we employed a scheme to compress the stanzas with a precalculated dictionary
Daniel
ralphm: I think the idea in sending the entire stanza is that the app server can make the decision
Daniel
And either just make the judgment call between priority or not.
ralphm
Sure, for calling this is also important as it allows for much quicker call setup.
Daniel
Or do something else like the compression thing
ralphm
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.
ralphm
Not sure if the same is really an issue for group chats
ralphm
That's less time critical.
Daniel
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
mimi89999has left
rtq3has joined
mimi89999has joined
Daniel
> 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
ralphm
Maybe it is good enough for a client to just be woken by its server (implementing push) and then retrieve MAM history.
ralphm
(for group chat, not calls)
ralphm
Note that services like Slack don't guarantee immediate notification, but rather in the few-seconds range.
ralphm
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.
Daniel
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
ralphm
I'm not talking about local system notifications, those are not really related
Daniel
I was told on iOS they kinda are
ralphm
I.e. your app can definitely get push notifications without the user seeing any notification.
Daniel
If you want to use high priority
Daniel
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
Daniel
But I was told on iOS that's not that easy
ralphm
Requiring high priority notifications for MUC seems like an edge case.
ralphm
I.e. if messages in a group are so highly time sensitive, maybe you are using the wrong medium.
ralphm
And yeah, iOS is picky. Android has been tightening stuff down, too.
ralphm
Now we're slightly on the topic, how is that notification channel separation between one-on-one, mentions, other group messages coming along? 😋
Daniel
It's still on my todo list.
ralphm
😃
zachhas joined
waqashas left
adityaborikarhas left
adityaborikarhas joined
waqashas joined
madhur.garghas joined
remkohas joined
madhur.garghas left
debaclehas joined
lskdjfhas left
lskdjfhas joined
wurstsalathas joined
Holger
> 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.
Guushas left
Guushas joined
wurstsalathas left
wurstsalathas joined
Nekithas joined
rtq3has left
Guushas left
Guushas joined
rtq3has joined
ralphm
I wasn't comparing 1:1 to group, rather messages vs. calls.
UsLhas joined
neshtaxmpphas left
Guushas left
Guushas joined
karoshihas left
karoshihas joined
ralphm
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.
ralphm
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.