ralphmDaniel: issues with sending XEP-0357 to include body or potentially the whole stanzas: privacy and size limits
Danielralphm: if this is in response to my tweet I was mostly referring to the paragraph following 'business rules. Not necessarily the entire section.
ralphmFor 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
DanielCommunicating what triggered the push is complicated ™ and I don't have a good solution for that
ralphmSo we employed a scheme to compress the stanzas with a precalculated dictionary
Danielralphm: I think the idea in sending the entire stanza is that the app server can make the decision
DanielAnd either just make the judgment call between priority or not.
ralphmSure, for calling this is also important as it allows for much quicker call setup.
DanielOr do something else like the compression thing
ralphmI.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.
ralphmNot sure if the same is really an issue for group chats
ralphmThat's less time critical.
DanielIn 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
ralphmMaybe 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)
ralphmNote that services like Slack don't guarantee immediate notification, but rather in the few-seconds range.
ralphmBut sure you only have limited time to do something in response to a notification, so you either need some body, or a fast reconnect.
DanielYes 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
ralphmI'm not talking about local system notifications, those are not really related
DanielI was told on iOS they kinda are
ralphmI.e. your app can definitely get push notifications without the user seeing any notification.
DanielIf you want to use high priority
DanielBut 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
DanielBut I was told on iOS that's not that easy
ralphmRequiring high priority notifications for MUC seems like an edge case.
ralphmI.e. if messages in a group are so highly time sensitive, maybe you are using the wrong medium.
ralphmAnd yeah, iOS is picky. Android has been tightening stuff down, too.
ralphmNow we're slightly on the topic, how is that notification channel separation between one-on-one, mentions, other group messages coming along? 😋
DanielIt'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
ralphmI wasn't comparing 1:1 to group, rather messages vs. calls.
UsLhas joined
neshtaxmpphas left
Guushas left
Guushas joined
karoshihas left
karoshihas joined
ralphmFor 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.
ralphmI'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.
XSF Discussion - 2019-07-13