61–70 of 150 posts
So this is welcome, but it requires application support. And if apps on your phone use both GCM and UnifiedPush you still end up with multiple providers. But at least I think I can trust UnifiedPush to be light on my battery.
Off-topic: Sometimes I work on ships that have Wi-Fi for talking to local services, but due to strict metering, Internet access is usually disabled. So most of the time there's no way to get notifications from monitoring systems and your fellow crew, let alone shoreside team members. It would be nice to have a solution for delivering pushes internally, and also hold open a best-effort connection to a remote server th…
https://github.com/gotify/android
The problem is that there is no iOS app. You could use the browser there but maybe ntfy would be a better fit (Android + iOS.)
Off-topic: Sometimes I work on ships that have Wi-Fi for talking to local services, but due to strict metering, Internet access is usually disabled. So most of the time there's no way to get notifications from monitoring systems and your fellow crew, let alone shoreside team members. It would be nice to have a solution for delivering pushes internally, and also hold open a best-effort connection to a remote server th…
... email?
Earlier quoted context omitted.
Thanks for your great work creating this protocol. Hope more app developers add support for it, especially for privacy focused apps like Signal which by relying on Google servers are leaking metadata.
If you deliver notifications, you are always leaking metadata around timing. A police unit parked outside a guy’s house and confirmed it was him in the real time chatroom, by cutting his internet and seeing him drop off. If you want real anonymity on the Internet, never use push notifications. Always “pick up your mail” periodically from random endpoints on the Web.
Earlier quoted context omitted.
I believe the notifications used to be delivered by a very long-lived TCP connection, and there probably is no limit to those on Android. The reason to use the google services is mostly touted as for battery savings, I believe.
Afaik Google and Apple just discount their own poller. It still has to wake up and check periodically.
Thus, it makes total sense to have one mechanism for push messages for the entire device. It's great to have degoogled alternatives here.
Earlier quoted context omitted.
Sorry if I’m not understanding something but… Doesn’t Apple and Google on the OS level only allow push notifications to come from its own services? Like, they look for the signature to be compatible with https certificate etc. Otherwise the phone could have a ton of push notifications incoming from anywhere on the Internet. The APN service for instance would only route notifications to a phone if it came from a regis…
Afaik Push is really Wake up one thing, Check one place, If (message) wake up correct app
Plus the real time push works differently… like a phonecall comes in and your phone rings thay same second
Apps draining your battery to check for notifications is the worst thing about degoogled Android. With notifications enabled my telegram client can drain my battery in a very low number of hours (got suggestions here? any client supporting UnifiedPush?) So this is welcome, but it requires application support. And if apps on your phone use both GCM and UnifiedPush you still end up with multiple providers. But at least…
It's possible. There is nothing ready right now.
[1] https://github.com/UnifiedPush/wishlist/issues/18
[2] https://github.com/Telegram-FOSS-Team/Telegram-FOSS/issues/5...
Earlier quoted context omitted.
Google famously tried allowing app keepalives to be synchronised... The scheduler allowed a wakeup in 'approximately' X minutes, and the OS would wake up and run all apps callbacks at once. If any app needed a wakeup at a precise time, then other callbacks at nearby approximate times would be run at the same time too. Overall, the thought was that wakeups are expensive, wakeups that involve the network are particular…
Seems like adding a random deviation to wakeup times would solve that problem.
Earlier quoted context omitted.
You can do that, but if keep alive are not synchronized (I don't think there is a mechanism to do so), you will wake more often if you keep more connections open. I think the OS could synchronize them if keep alive packets are sent at the TCP level, but that would be hard to do at a higher level. Letting a single program handle persistent connections leaves a lot more potential for energy efficiency optimizations.
> if keep alive packets are sent at the TCP leve Unfortunately there are lots of bits of hardware in mobile networks that fake acks - ie. TCP level acks will be received very quickly to indicate the mobile network has accepted the data, and will deliver it at some future time out to the internet. The problem is they still send acks even if the remote end is no longer responsive. So you can't reliably use TCP acks to…
In fact, I choose not to believe it. Is there some document discussing this kind of functionality?