I'm not actually sure iOS has this issue but android definitely appears to not let app developers listen to a websocket in the background based on my experience
@kepstin I'm well aware of why GCM exists :)
@iliana Heh, I just read https://hpbn.co/optimizing-for-mobile-networks/ recently, so I still have this stuff stuck in my head :/
@iliana yeah, going through Apple's servers is really the only way to do it on iOS. they're really strict on what is allowed for background tasks. Amaroq uses "background processing" to assist in its push notifications, but the initial signal still comes from APN.
@impiaaa so amaroq is running their own server to proxy pushes from the websocket then?
@iliana something like that. I remember it being explained that the proxy server doesn't actually see the content of notifications, to preserve privacy, so it just tells the app to "look for" new notifications (that's what the background processing is for). but I don't know what the server is checking if it's not the push websocket.
@impiaaa oh that's interesting.
I was actually thinking of maybe a way to register pushes with mastodon that included an encryption key, so that the proxy could subscribe to a push URL without seeing any of the content, and just passing it directly to the device
@iliana that would be neat, but it would be an upstream change that I don't find likely to get into mainline. 😞
@iliana It's really tough for phones in general, because for power saving reasons, having a persistent network connection open is basically the worst thing. You really want to be using a push notification service that hooks into the cell phone provider's ability to bundle a bunch of notifications together before remotely waking up the phone.