jdev - 2020-10-09

  1. marc0s

    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?

  2. jonas’

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

  3. marc0s

    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

  4. jonas’

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

  5. jonas’

    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

  6. eta

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

  7. marc0s

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

  8. eta

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

  9. marc0s

    eta, we don't, currently

  10. eta

    marc0s, ah okay

  11. eta

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

  12. marc0s

    eta, yes, sure

  13. jonas’

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

  14. marc0s

    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

  15. jonas’

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

  16. jonas’

    if they have push enabled

  17. jonas’

    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

  18. jonas’

    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

  19. marc0s

    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

  20. marc0s

    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...)

  21. jonas’

    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

  22. jonas’

    no value, in that it is a "lie"

  23. jonas’

    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.

  24. marc0s

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

  25. marc0s

    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)

  26. Wojtek

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