1. The F-Droid flavor of the app [1] does not require or use Firebase. And: If you self-host the server and use the Google Play flavor [2] of the app, it won't use Firebase either.
2. I've just started work [3] on making ntfy a UnifiedPush (https://unifiedpush.org) distributor, meaning that other apps/services will be able to use ntfy.sh (or a self-hosted server) as a means to deliver notifications or messages. I'm super excited about this, and I don't think it'll take very long.
I look forward to that. I wouldn't try it without unified push but if you add that, it could be easily be better than gotify which really only provides the bare minimum.
Hmm, I'm not very well versed in Android push messaging, but how does your self-hosted binary send notifications? Don't you need to include GCM keys somewhere?
A "foreground service" means 2 things: an unremovable notification is shown to the user in their notification tray AND specifically for ntfy, an additional connection open (additional battery usage) on top of the one engineered by Google.
Although I like seeing things attempt to compete with Google, this can't come close because of the restrictions of Android enacted by Google.
Yes, sadly Google/Android makes it impossible to do it in a battery efficient manner. UnifiedPush [1] is attempting to create a competitive mechanism that apps can use and share for notifications and server-to-device messages. There is still one open connection, but it can be shared by all apps on the phone.
I have recently started work to make ntfy a UnifiedPush distributor [2].
Side note:
- you _can_ actually dismiss the foreground service notification, see [3] for a screenshot
- the battery impact is not as severe as I had thought initially. On my phone, it's about 4% battery over 17h "use" [4]. I'm planning on making "slow delivery" possible to counter this bahavior, see this ticket [5]
I noticed UnifiedPush and your efforts there and I am curious. My summary after a brief glance is UnifiedPush will not achieve anything useful, for the same reasons: iOS and Android push notifications are locked down. For example, sure, Android is OSS, but most of the functionality is provided by proprietary apps or Google Play Services. This results is challenges today, but further challenges down the road (App Store rules/policies change, stronger enforcement).
About the battery usage, this is always a hard question to answer. 4% is very low, which seems good. But how could you measure that effectively? Perhaps if the connection is good, it might take 4% battery over 17h of "use". But could this be worse if network is intermittent (i.e. realistic conditions)? Or lots of data being used (or *abused*).
As binwiederhier said 'it is what it is' with proprietary platforms. However, you can still avoid going through Google now for the apps that do already support UnifiedPush
Additionally, supporting UnifiedPush (code and adoption by app devs) is supporting:
1. Non-google app stores (e.g. F-Droid with it's great selection of FOSS apps)
2. Google-free distributions of Android
3. Linux phones
The above amount to a small but non-trivial community, but imho supporting (or participating in) them ethically is something I like.
Yeah I mean it is what it is. We can all only work on the space that exists. The big boys control the market and the eco system.
One battery saving idea: there is a ticket to let the user control the interval at which the topic is polled. Right now it's obviously a persistent connection. But likely polling every 5min may consume less battery.
Ahh, thanks, that clarifies things! One feature request I had was to use encryption so FCM can't read your notifications, but that might not be what your service is for.
Unfortunately, Firebase requires Google services. UnifiedPush integration would be nice