jdev - 2020-10-09

hi, how do you handle push notifications client-side? Do you always resume the SM session on receiving a push notification or if there's no interaction you stay hibernated? What would be the expected behavior?

I think that at least one implementation will time out your SM session if you don’t resume after a push

I know also of one that does this, I was asking if that's the desirable behavior from the users' point of view, as I think it's not uncommon to ignore incoming pushes for some period of time (let's say more than 600s) but you still want them to keep coming in, if any

marc0s, some push implementations also require you to SM-resume (or do other magic) to obtain the message content

hence you’ll have to do that to show the correct info (such as "who sent the message" and the message content) to the user, for them to decide whether to ignore it or not

yeah as far as I understand the push content is just "go connect again, there's something to fetch"

jonas’ uhm, that's right, didn't thought of that scenario; we're just sending the full message in the push notification 😅

marc0s, do you not have end-to-end encryption

eta, we don't, currently

marc0s, ah okay

the issue with sending the actual push body though is Apple/Google get to read it

eta, yes, sure

is it in their ToS that they are allowed to do things with the push notification body?

nonetheless, if the server is not aware of the existance or not of e2e, why should the server determine that the client _must_ SM-resume after sending a push notification? I see no relevant difference on a SM-suspended session that has received a push notification and one other that doesn't (in SM-terms or server-side resources used) so the first one should be dropped after some time and not the latter

marc0s, ah, the implementation I was talking about keeps SM sessions "forever"

if they have push enabled

the assumption is that if they have push enabled, the session is worthy of being hibernated longer, because it can be woken up on request by the server

so it is in fact a difference in resource consumption, because with push, the SM session may stay hibernated on the server for longer than the usual timeout

jonas’ that's what I'd expect; but prosody's mod_smack adds another condition to keep the hibernation forever: have no push delivered yet https://hg.prosody.im/prosody-modules/file/tip/mod_smacks/mod_smacks.lua#l493 So, after sending out a push notification, that SM-hibernated session is elegible for being dropped

I can see the difference of resource consumption between a push-enabled and another session without pushes enabled, but I cannot see it between two sessions with enabled pushes where a push notification has already be sent to one but not to the other (I'm no sure if I'm explaining myself quite ok...)

marc0s, the assumption is: if the push isn’t being answered by resumption, there is a problem with the client (got uninstalled, the phone is completely turned off, has lost coverage for good etc. etc.), and there’s no value in keeping the session open

no value, in that it is a "lie"

with push-less SM, you cannot distinguish between a client crashing and a client coming back in a minute or two because it just lost the network connectivity for a short amount. hence there is a timeout to expire sessions which are not likely to get resumed.

I see the push-less assumption, I'm not sure I share the first

response codes from the push provider (APNS, FCM,...) should indicate if the push recipient is no longer valid and from that we could infer that the session should be dropped; but assuming that a lack of interaction of the user means the session should be dropped... idk (I assume my use case does not require any reconnection because the push has all the info, and this may not always be the case)

@marc0s sometimes it's not possible to include complete message in the push notification which may warrant reconnection