UnifiedPush: A decentralized, open-source push notification protocol
1–10 of 150 posts
Re: UnifiedPush: A decentralized, open-source push notification protocol
#2Wow, that was submitted here quicker than we could do it!
UnifiedPush has been a thing for a while, see the official website: https://unifiedpush.org/
With this blog post, we† tried to clarify a few names. Feel free to point out things that are still unclear, the documentation is pretty much a WIP.
UnifiedPush aims at replacing the push notifications mechanism provided by Google services with something independent, that anyone can self-host or any OS can provide without compatibility issues. It does require small adjustments server-side and client-side for applications assuming Google services.
There is also a Matrix room at #unifiedpush:matrix.org and a Mastodon account at https://fosstodon.org/@unifiedpush
Note: we'll be monitoring this topic for a while, you don't have to reply to this thread.
† karmanyaahm and S1m are main authors
Re: UnifiedPush: A decentralized, open-source push notification protocol
#3>However, if each app actively maintains a server connection, the OS cannot suspend them.
This is a limitation with Android and not a fundamental network/OS limitation. As long as your protocol allows for long enough keep alive latency you can periodically wake up for a short period and allow apps to service their connections (which is what I'd imagine this does anyway just with a singular app.) This works on Linux if you don't have the extra Android crap getting in the way.
It's kind of a bummer to see bad OS architecture feed into over-complicated protocol/application design.
EDIT: I guess I wasn't clear here. In my experiments I had the background wake up service wake the device up once and applications had just that singular window for all of them to service their connections. The problem with Android is instead applications either keep the phone from suspending entirely or (apparently) have some API allowing them to register their own periodic wake up that isn't shared.
EDIT2: I also want to be clear that this isn't a criticism of NTFY. The developers behind it deserve congratulations for solving a serious problem with FOSS Android apps. My complaint is that the poor architecture and unescisary inflexibility of Android made this such a complex problem in the first place.
Re: UnifiedPush: A decentralized, open-source push notification protocol
#4Wow, that was submitted here quicker than we could do it! UnifiedPush has been a thing for a while, see the official website: https://unifiedpush.org/ With this blog post, we† tried to clarify a few names. Feel free to point out things that are still unclear, the documentation is pretty much a WIP. UnifiedPush aims at replacing the push notifications mechanism provided by Google services with something independent, t…
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.
Re: UnifiedPush: A decentralized, open-source push notification protocol
#5Looks like a cool solution to one of the biggest issues in FOSS on Android.
Re: UnifiedPush: A decentralized, open-source push notification protocol
#6Wow, that was submitted here quicker than we could do it! UnifiedPush has been a thing for a while, see the official website: https://unifiedpush.org/ With this blog post, we† tried to clarify a few names. Feel free to point out things that are still unclear, the documentation is pretty much a WIP. UnifiedPush aims at replacing the push notifications mechanism provided by Google services with something independent, t…
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.
Regarding Signal, I don't think they have been approached yet... https://github.com/UnifiedPush/wishlist/issues/8
I think the consensus was that we wanted to wait for UnifiedPush to be more mature before approaching them, but it's probably about time. S1m made an interesting implementation for the (compatible) Signal fork Molly: https://github.com/mollyim/mollyim-android/pull/152
The implementation is quite interesting: it adds a linked device that does not receive encryption keys, but sends push notifications to the client.
Re: UnifiedPush: A decentralized, open-source push notification protocol
#7Wow, that was submitted here quicker than we could do it! UnifiedPush has been a thing for a while, see the official website: https://unifiedpush.org/ With this blog post, we† tried to clarify a few names. Feel free to point out things that are still unclear, the documentation is pretty much a WIP. UnifiedPush aims at replacing the push notifications mechanism provided by Google services with something independent, t…
Uh, the site doesn't load...
Re: UnifiedPush: A decentralized, open-source push notification protocol
#8>However, if each app actively maintains a server connection, the OS cannot suspend them. This is a limitation with Android and not a fundamental network/OS limitation. As long as your protocol allows for long enough keep alive latency you can periodically wake up for a short period and allow apps to service their connections (which is what I'd imagine this does anyway just with a singular app.) This works on Linux i…
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.
Re: UnifiedPush: A decentralized, open-source push notification protocol
#9>However, if each app actively maintains a server connection, the OS cannot suspend them. This is a limitation with Android and not a fundamental network/OS limitation. As long as your protocol allows for long enough keep alive latency you can periodically wake up for a short period and allow apps to service their connections (which is what I'd imagine this does anyway just with a singular app.) This works on Linux i…
I would think that in order to not have an obvious negative impact on battery life, it would be necessary for the OS to coalesce app notification service keepalives, performing them in scheduled batches instead of the moment an app requests one. That should be roughly equal to the current situation with APNS/GCN, where the OS can schedule network maintenance during periods where the device and antenna(s) are likely to be awake already.
Re: UnifiedPush: A decentralized, open-source push notification protocol
#10Wow, that was submitted here quicker than we could do it! UnifiedPush has been a thing for a while, see the official website: https://unifiedpush.org/ With this blog post, we† tried to clarify a few names. Feel free to point out things that are still unclear, the documentation is pretty much a WIP. UnifiedPush aims at replacing the push notifications mechanism provided by Google services with something independent, t…
Uh, the site doesn't load...
Looks like IPv6 is broken :/
The AAAA record was temporarily removed to try to mitigate.