Is it possible for every app developer to stop using FCM? Yes, in China.<p>The result is a chaotic market. App devs will have to use multiple push machinism for different device: on Huawei phones, Huawei's own push service is the most reliable; on other phones, you might want use SDKs from Tencent/Baidu/Alibaba so their app (Wechat/Baidu search/Taobao/Alipay) can "wake up" your app to receive push. Battery life become miserable, push become unreliable. It's to a point where the government start "regulating" the market (the Unified Push Alliance, <a href="http://www.chinaupa.com" rel="nofollow">http://www.chinaupa.com</a>, is lead by CAICT, a think tank of Gov of China).
This is really the chance for a great open source project. So many open source apps (Signal, Mastodon clients, riot.im, telegram-foss and more) have to do hacks to be able to deliver push notifications without GCM/FCM<p>What if there was an open source software one could setup on a server that would provide push services for all these apps and would interact with one open source client running on android.<p>That way one would have the energy saving benefits of only handling one server connection, but the privacy benefits of a private server for oneself/friends/people one trusts.<p>This is definitely not easy and would require coordination between many open source projects and also additions in Android to run on a system level (maybe in lineageos and similar), but I really think it would be worth it.
> <i>Wouldn’t it be great if the user could just pick a “push notifications provider” in the phone settings and OS managed all these hard details by itself? So every app, which doesn’t want to be policed by the platform owner, didn’t have to invent the system anew? It could be end-to-end encrypted between the app and the app server. There’s no real technical difficulty in that, but as long as our systems are controlled by big players who do not allow this, we have to solve it by ourselves.</i><p>Fking this. ideally, this would also involve a standard API on the backend for how to send push notifications. E.g., something like:<p>1) App on phone queries OS for selected push provider.<p>2) Phone OS returns some metadata about the push provider to the app, including a a backend URL for sending messages.<p>3) App sends that URL to it's own backend server.<p>4) When a push message should be sent, the app's backend server invokes that URL with the message to be sent in some standardized way.<p>If - which is likely - push servies require that developers register their apps with them before use, this could be expanded by the phone OS returning a list of providers instead of just one.
People migrating from GCM to FCM need to be aware that in FCM analytics are turned on by default: <a href="https://github.com/siacs/Conversations/issues/3041" rel="nofollow">https://github.com/siacs/Conversations/issues/3041</a>
>SSE fits our needs better than WebSocket would (it is cheaper and converges faster, because it’s not duplex). We’ve seen multiple chat apps trying using WebSocket for push notifications and it didn’t seem power efficient.<p>This is just not true unless there is some serious fuckery going on with the websocket implementation. Both require full duplex communications on the transport layer.
I'm wondering how it works with different messaging apps. I'm using mostly Facebook Messenger, because of the network effects. A few months ago I tried to use several apps to communicate with my wife. Both Signal and Wire failed to reliably send messages in under 30 minutes or so. More often then not the message would be delivered after a few hours. That's totally unacceptable. If there are some magic settings in Android they were not properly advertised. Our phones are on quite pure 8.1 and 7 versions. So I'm back to Messenger.<p>Reading this it seems that there is a known solution to this problem. Does Mastodon offer something like private messages? Or is there a messaging app that doesn't use FCM, but works in a way described in article?
<i>Final thought: Every user should be able to choose a “Notification Provider” for every app</i><p>At Qbix, we thought deeply about this problem. Ideally, to maintain anonymity, each notification would come from some random endpoint on the cloud. But that’s not how the Internet works these days, you have to connect periodically to SOMETHING. So you can choose your own notification providers.<p>The trouble is if you have many apps, then your device is constantly connected to many servers.<p>What we settled on for now is a background process with WebSockets, but perhaps this works better. The operating systems weren’t designed for this use case and the phones aren’t optimized for it. For example, how would you do the same on iOS?<p>However, what IS possible is tunneling through the native iOS VoIP notifications support and encrypting your notifications. You can even process them on the client side with some “IFTTT” type logic. To do that for Android, however, we had to implement this background process approach. But it’s a hack.
What's the deal with push notifications if the modem has to be switched on every couple of minutes to keep a connection alive? I was under the impression that push notifications were implemented similar to a call handshake that only activates the phone if there is a call.<p>Are the FCM service and the iOS equivalent also IP based or can they use some lower level, more energy efficient protocols to wake up the phones?
> Wouldn’t it be great if the user could just pick a “push notifications provider” in the phone settings and OS managed all these hard details by itself?<p>Having the possibility of choice is a good thing but in this particular case I don't think it would be good if 3rd party notifications providers were available. This should be an integral part of the OS, not a field for competition; knowing that Google itself can harvest data from notifications we can't exclude the possibility that there would appear companies interested only in that activity, at the same time enticing users with pretty and simple design of notifications or whatever else.
<i>Another difficulty was caused by the Doze mode, introduced in Android M. The Doze, which is turned on after a period of inactivity, among other things prevents background processes to access the network. As you can imagine, this prevents our app from receiving notifications.</i><p><i>We mitigate this problem by asking users to make an exemption from battery optimisations for our app. It worked fairly well.</i><p>This is why we were migrating to FCM from our own custom built MQTT solution that was invented back in 2012.
This is a very exciting development, it's great to see more developers take this centralisation issue seriously.<p>On this subject, many people including myself have been failing (hard) to convince Moxie that dropping FCM (or GCM or whatever the name) is the way to go for Signal, if anyone want to give a hand...<p><a href="https://www.reddit.com/r/signal/comments/9ekawn/moxie_drop_the_gcm_requirement_already/" rel="nofollow">https://www.reddit.com/r/signal/comments/9ekawn/moxie_drop_t...</a><p><a href="https://github.com/signalapp/Signal-Android/issues/7638" rel="nofollow">https://github.com/signalapp/Signal-Android/issues/7638</a>