Notifications: Out of the comfort zone?
-
Hello,
seems like questions about notifications turn up every other day or so. Main questions are:
- Will notifications continue to work (actually only Telegram-related it seems)?
- How about putting notifications into Dekko (or other Apps) without a push server?
Regarding question 1: Currently notifications are being pulled from the Canonical push servers, which in turn receive them from some 3rd party source (e.g. Telegram servers). So easy answer, as soon as Canonical turns off the push servers, our notifications will cease to function.
UBports currently has no plans to replicate the push server infrastructure. First of all the code for the push service is not open-source, and we cannot just fork it and continue. Then, many people said they dont want to have the user´s private data on any server. The plan is still to replace the central push server architecture with local pushed messages. But no details are agreed up to now.
Regarding question 2: You saw from question 1 that there is more infrastructure in play than just the phone itself. For example, email protocols are not well prepared for push notifications: POP3 does not have any part in the protocol that can deal with that, and IMAP has limited support, the client needs to subscribe for folder change notifications, but then needs to stay online. If the client times out (loss of network, sleep mode etc) the server will remove that subscriptions, and nothing gets pushed.
In fact most of the services that were not written with mobile disconnected devices in mind will not cover that request. So its not only on UBports side that this is a problem. That´s why Apps were developed, why new services were created, and why old services (lile emails) loose traction.
Here is my personal opinion, and not the official one from UBports: We will require a push server (actually a few nodes for scaling & redundancy). Most 3rd parties that support notifications will not want the traffic of devices constantly polling from their servers (and creating full sessions jsut to close them again), and they are used to work with push servers from Google & Apple. Then, the preparation of the notification can be done on the server, and the polling is very cheap (No complex session with lots of crypto handshake etc). However, they shall be SSL-encrypted at least.
Every direct check from the client every x minutes costs battery. If every App checks itself this is multiplied. So for data transfer, CPU & battery savings, I think this is necessary. The details of the data storage can be discussed (even full encrypted data is maybe possible).
For Dekko: It´s a mailbox security issue: For the push server to check for mails, he would need the current username & password (though password can be hashed and is not in plaintext) to query your mailboxes. I think push notifications for traditional mailboxes are almost impossible.
BR
-
Regarding question 1 I think that the main problem is the push server code. But if we could create a push server program, people that don't want their data in someone else's server could run the program on their own workstation, so this is not a so big problem, in my opinion. Anyway the data should be stored in a strongly encrypted mode.
-
I am not sure I am getting much wiser from this post, although I better understand the challenges.
In my view, the platform needs some kind of notification service to work, even at the sacrifice of battery. A mobile device without proper notifications is rather crippled. So, if push is too difficult to implement, maybe there could be some kind of "pull service" that could be enabled/disabled on a per app basis?
-
I'm completely ignorant, but does every phone brand have a push server for Telegram, for instance? Or all the Android devices use Google services for this?
-
@wgarcia No they are using Google´s https://developers.google.com/cloud-messaging/ for example. It has nothing to do with the phone brand, only with the operating system.
-
@tomoqv said in Notifications: Out of the comfort zone?:
s too difficult to implement, maybe there could be some kind of "pull service" that could be enabled/disabled on a per app basis?
Yes basically possible. Only disadvantage is that every App has to implement a "lean worker" that does some job and can be called form the outside, optionally allowing forceful termination if it hangs or suddenly consumes 100% CPU etc. For example in Telegram that means to establish a full session to the network, filter groups that are not muted, count the messages and finally send the result locally. The session initiation in Telegram is not cheap - its heavy lifting, because it is expected to do it only once. And thats causing battery drain. One App is ok, imagine several messengers, sync clients (calendars) etc. All of them need to make their heavy session construct & teardown every 5mins or so... Thats why push was invented xD
-
@garro said in Notifications: Out of the comfort zone?:
uld run the program on their own workstation, so this is not a so big problem, in my opinion. Anyway the data should be stored in
No thats not so easy. Services like Telegram want to send actually notifications to one service only. If we can get the same agreement like Canonical had with Telegram they will require actually us to accept their data flow on a stable server. How we could get individual agreements with all users towards Telegram
-
As for question 2, when I was working in Canonical I made a change to account-polld (the service which gets invoked every 5 minutes in your device to check if you have new notifications for any of your accounts) and I rewrote it in order to allow third party developers to write plugins for it.
Plugins are in fact separate processes which communicate with the daemon via JSON messages (in a format similar to the one used by the push server), so they can be written in any language.The code for the service is here: https://github.com/mardy/account-polld
The existing plugins (written in Go) are here: https://github.com/mardy/account-polld-plugins-goUnfortunately these changes got never merged into trunk, so if someone is making new images, please use the links above for building these components.
I'm willing to maintain and develop further these components in my spare time (same goes for the Online Accounts feature which I was maintaining in Ubuntu), so feel free to reach out to me in case you have questions on how to use them.
-
I'm starting to understand the complexity of notifications without the support of Canonical. It looks like we will have to go back to SMS for a while, fortunately they are free at least for me nowadays.
-
@Flohack Is not possile to poll the servers through Telegram APIs, as we would without the push service or when you are on the desktop? The same you could do with e-mails.
The Workstation/server wouldn't have battery problems, so it's not a problem to poll frequently. -
How does Sailfish handles telegram notification ? I'm not sure that their telegram app is officially supported.
-
@ernest I dont know, maybe you can find out?
BR -
@garro Can you explain? You mean you run a separate software on your Desktop which will create the notifications and send them to the phone?
BR
-
Could we just store the notifications locally? There's no real advantage to not doing it.
-
If we're talking about Sailorgram, the app is launched at startup, running as a daemon invoked by systemd. When the user taps its icon in the apps launcher, a message is sent to the app via DBus, requiring to show the GUI. When the user close that GUI, the main process keeps running in background.
This might be a solution, but it involves a revision of the confinement policies and the whole app life-cycle story.
EDIT: I'd like to make it clear, daemons are something shouldn't be implemented in the current platform, IMHO, since they might be a bit dangerous...
-
We can't live without any background services forever, so would it maybe be possible to have a background daemon where applications can register micro-services that the user can allow or block? That way applications could have stripped-down background options (to poll for notifications, for example) and the user could decide between functionality or battery life and you don't need a notification server and everything can be done on the client-side. I understand that it would be a lot of work and it's probably only feasible for the non-legacy, but might that be an option?
-
@NeoTheThird
If I try to understand the strategy Canonical used for writing the current platform limitations, I see that running daemons - without any particular limitation - might turn to be too risky.There's already some way someone could potentially write an app that "soft-bricks" the device, but the only thing that prevents it is the absence of daemons - yep, it's something very stupid I've tried some time ago. XD
This is clearly one of the bad scenarios I can think of right now, but it's still something to consider if you want to change the current strong confinement policies, IMO.We actually need to think at a solution - that's true - which could be something similar to BlackBerryOS 10, or just running a daemon like in SailfishOS (BTW, apps with daemons are not allowed to be released in the SFOS store).
In any case, if we want to allow applications to be run as daemons, then, I would suggest that those apps needs to be open source, in order to be manually examined before they get released on the Open Store. -
@sverzegnassi Ok, i did not express myself clearly there: My point was to not let every app break the confinement rules and create their own background services, my point was to create a unified master-service that applications can then can ask to register their own service on (with the user moderating it). This is not only useful for notification services, but also for other background services like music playback with the screen switched off, which is a really nice feature.
I totally agree with you, we can't have every app going around being a cowboy, but practicality beats purity. We should definitely restrict closed-source apps from breaking confinement, but of course this is no guarantee for safety either. You can easily hide malicious functionality in a block of obscure code... We should not panic too much about this, though.
Tangent:
Some points of confinement will have to be over-thought, like the content-hub for example. Of course it makes sense to have rules in place, but practicality beats purity. A calculator app does not need to have write access to the home folder, for example, but a text editor does. And creating local copies for everything seems a little weird... -
@NeoTheThird said in Notifications: Out of the comfort zone?:
ack with the screen switched off, which is a really nice fea
I think it's an essential feature
-
@Flohack Exactly, when the phone connects to it asking for them
