Push-Notification
| |
Push notifications are generally about telling inactive apps to contact your server to get new messages. This requires special servers as well as distributor apps that take over this task.
In Android systems, a basic distinction can be made between Google’s “Firebase Cloud Messaging” (FCM) and the independent “Unified Push” (UP), both of which use the same protocol.
However, the advantages of potential energy savings through apps that do not have to be permanently active also come with disadvantages in terms of data protection and security. More on this >> here <<.
Unified Push
With “Unified Push” (UP), it is thus possible to implement push functionality independently of Google and without Google servers. However, apps must explicitly support “UP” for this. Examples for Mastodon for this are the apps “Tusky” and “Fedilab”. The latter app is also for Pleroma, Friendica and Pixelfed.
You can then freely choose both the push server and the distributor app (“Distributor”).
Initial situation
… using the example of Mastodon and Conversations:
The Mastodon app is not always active on Android. But you want to be informed immediately when messages arrive (push) - even if “run in background” is disabled.
Requirement
The Mastodon app registers with a distributor app that keeps a permanent connection to the internet open anyway. This app must always be active and can therefore always be connected to the push server. Since the standard protocol XMPP is very well suited for this, this information/distribution function can currently be fulfilled e.g. by Conversations.
Procedure
- a message is received by Mastodon
- mastodon sends an information about it to the configured push server
- the push server sends a message to Conversations
- conversations sends a grow signal to android or the mastodon app
- the Mastodon app starts and then retrieves the messages from Mastodon
Source of the (supplemented) graphic: unifiedpush.org
Expert knowledge
There are push distributors that use different technologies. For example, there are “Websockets”, “HTTP” or “XMPP”. However, XMPP is superior when connections are to be held for a long time and in efficiency.
Conversations FAQ
In the frequently asked questions about Conversations, you can find various information about push notification.
How do XEP-0357: Push Notifications work?
You need to be running the Play Store version of Conversations and your server needs to support push notifications.¹ Because Google’s Firebase Cloud Messaging (FCM) are tied with an API key to a specific app your server can not initiate the push message directly. Instead your server will send the push notification to the Conversations App server (operated by us) which then acts as a proxy and initiates the push message for you. The push message sent from our App server through FCM doesn’t contain any personal information. It is just an empty message which will wake up your device and tell Conversations to reconnect to your server. The information sent from your server to our App server depends on the configuration of your server but can be limited to your account name. (In any case the Conversations App server won’t redirect any information through FCM even if your server sends this information.)
In summary Google will never get hold of any personal information besides that something happened. (Which doesn’t even have to be a message but can be some automated event as well.) We - as the operator of the App server - will just get hold of your account name (without being able to tie this to your specific device).
If you don’t want this simply pick a server which does not offer Push Notifications or build Conversations yourself without support for push notifications. (This is available via a gradle build flavor.) Non-play store source of Conversations like the Amazon App store will also offer a version without push notifications. Conversations will just work as before and maintain its own TCP connection in the background.
Source: github.com/iNPUTmice/Conversations (external)
But why do I need a permanent notification if I use Google Push?
FCM (Google Push) allows an app to wake up from Doze which is (as the name suggests) a hibernation feature of the Android operating system that cuts the network connection and also reduces the number of times the app is allowed to wake up (to ping the server for example). The app can ask to be excluded from doze. Non push variants of the app (from F-Droid or if the server doesn’t support it) will do this on first start up. So if you get exemption from Doze, or if you get regular push events sent to you, Doze should not pose a threat to Conversatons working properly. But even with Doze the app is still open in the background (kept in memory); it is just limited in the actions it can do. Conversations needs to stay in memory to hold certain session state (online status of contacts, join status of group chats, …). However with Android 8 Google changed all of this again and now an App that wants to stay in memory needs to have a foreground service which is visible to the user via the annoying notification. But why does Conversations need to hold that state? XMPP is a statefull protocol that has a lot of per-session information; packets need to be counted, presence information needs to be held, some features like Message Carbons get activated once per session, MAM catch-up happens once, service discovery happens only once; the list goes on. When Conversations was created in early 2014 none of this was a problem because apps were just allowed to stay in memory. Basically every XMPP client out there holds that information in memory because it would be a lot more complicated trying to persist it to disk. An entire rewrite of Conversations in the year 2019 would attempt to do that and would probably succeed however it would require exactly that; a complete rewrite which is not feasible right now. That’s by the way also the reason why it is difficult to write an XMPP client on iOS. Or more broadly put this is also the reason why other protocols are designed as or migrated to stateless protocols (often based on HTTP); take for example the migration of IMAP to JMAP.
Source: github.com/iNPUTmice/Conversations (external)
Conversations Push Proxy
Due to restrictions in Firebase Cloud Messaging (and most other push services), only the developer can create push notifications for their apps. For this reason a user’s server wouldn’t be able to wake up a user’s device directly but has to proxy that wake up signal through the infrastructure of the app developer.
Here is a quick description of how this relationship is set up.
All examples below use real world values from my personal device with a test account. The fact that I’m comfortable making that publicly available can act as an indication on how non privacy sensitive that data is. …
Source: github.com/iNPUTmice/Conversations (external)