-
ralphm
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
-
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
😃
-
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.
-
ralphm
I wasn't comparing 1:1 to group, rather messages vs. calls.
-
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.
-
ralphm
Sometimes good enough is good enough.
-
ralphm
Holger: ^
-
Holger
Ah, right.