Live data from Hacker News

UnifiedPush: A decentralized, open-source push notification protocol

f-droid.org

51–60 of 150 posts

Re: UnifiedPush: A decentralized, open-source push notification protocol

#51

Earlier quoted context omitted.

UnifiedPush is compatible with WebPush: both just involve an HTTP POST to a specific URL. If your application server supports WebPush, it can send encrypted notifications to UnifiedPush servers (that is how we're planning to support Telegram, for example). You can then decrypt these notifications in the app [1]. However, some protocols only send a wake-up ping or random ID in the push notification, Trifa and Matrix r…

> There, encryption is unnecessary complexity. If you are sending a small amount of data it is likely a tiny overhead for some notable benefits. 1. If all data is encrypted then no data stands out for being encrypted. 2. It provides integrity which may prevent push servers from changing message to be invalid or triggering parsing bugs in applications. 3. If only encrypted messages are supported it is impossible for u…

I agree that mandatory encryption would massively help privacy, integrity and even compliance [1]. However, the main cost is developer-effort involved in keeping track of keys and implementing encryption.

As a small project, ease of adoption has been our most important goal. However, as we work towards better WebPush compatibility [2], I personally absolutely want to promote RFC8291 encryption and make it easy to implement for developers using UnifiedPush, hopefully making it the norm.

[1] https://volkerkrause.eu/2022/11/12/kde-unifiedpush-push-noti...

[2] https://github.com/UnifiedPush/wishlist/issues/15

Re: UnifiedPush: A decentralized, open-source push notification protocol

#52

Earlier quoted context omitted.

Yes, the WebPush standard provides protocols for both. This is necessary because otherwise there wouldn't be an intercompatible way for backends to send notifications to different browsers. The protocol for the federation of notifications would be the most useful for other non-JS projects to reuse, so that backend developers can plug any native app in their existing webpush support without coding yet another system.

I think GP got it backwards, actually: Web Push seems to have a wire interface for submission and a JavaScript API for subscription, while the internals of how the notifications get from e.g. the FCM backend to the notification drawer on your Android phone remain unspecified (and partly secret). UnifiedPush has a wire interface for both submission and subscription+reception, plus an Android(?) intent API for interact…

> while the internals of how the notifications get from e.g. the FCM backend to the notification drawer on your Android phone remain unspecified (and partly secret)

Actually, the web push standard strongly recommends that you use RFC 8030 for this, but it does allow browsers to substitute other protocols as long as their semantics are the same https://datatracker.ietf.org/doc/html/rfc8030. I believe Mozilla and Edge both use HTTP Push, I'm not sure what Google uses on Desktop Chrome but I could see it going either way. Safari probably uses APNS.

Re: UnifiedPush: A decentralized, open-source push notification protocol

#53

Earlier quoted context omitted.

From the blog post: > One key feature of UnifiedPush is that the communication between the push server and the distributor is not specified. This means that a variety of technologies can be employed, such as WebSockets, Server-Sent Events, *XMPP*, raw TCP, or even SMS, whatever works best for the user.

Sigh. What you miss is that this protocol introduces nothing that already isn't done by XMPP push notifications. It is decentralized, it can deliver to different endpoints, etc. You only need to create a dispatcher app that will relay the notifications to third party apps. Again, this too was done years ago.

So what! Few use that. I host a prosody server with lots of plugins and it never occurred to me to use it, let alone use cases outside if the XMPP ecosystem. Can the XMPP implementation fall back to google's push system. Does it have a blog entry, lovely diagrams, comprehensive docs, a nice on-boarding experience for developers? Ideas aren't worth much, implementation--getting things done is what matters.

Re: UnifiedPush: A decentralized, open-source push notification protocol

#54
post #34
post #2

Wow, 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…

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…

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.

Re: UnifiedPush: A decentralized, open-source push notification protocol

#56

Earlier quoted context omitted.

> There, encryption is unnecessary complexity. If you are sending a small amount of data it is likely a tiny overhead for some notable benefits. 1. If all data is encrypted then no data stands out for being encrypted. 2. It provides integrity which may prevent push servers from changing message to be invalid or triggering parsing bugs in applications. 3. If only encrypted messages are supported it is impossible for u…

I agree that mandatory encryption would massively help privacy, integrity and even compliance [1]. However, the main cost is developer-effort involved in keeping track of keys and implementing encryption. As a small project, ease of adoption has been our most important goal. However, as we work towards better WebPush compatibility [2], I personally absolutely want to promote RFC8291 encryption and make it easy to imp…

Making it the "norm" isn't good enough, because developers will always want to cut corners to ship, either based on pressure from management or (in open source projects) just not feeling comfortable with encryption or thinking that it's important enough to implement. Web push libraries are already widely available for major languages to handle implementing encryption, and keeping track of keys isn't any harder than keeping track of device IDs or endpoints would be without encryption—it's just one more row in your database.

Re: UnifiedPush: A decentralized, open-source push notification protocol

#57
AFAIK Modern Android (>= 8.0) reserves the right to kill your app when running in the background unless there's a foreground toast bound (even then, can still be killed in low memory situations). How does this solution work around that? Is there a need to opt into the legacy "battery saver disabled" mode for the app which more closely mirrors <= 7.0 execution model?

Re: UnifiedPush: A decentralized, open-source push notification protocol

#58

AFAIK Modern Android (>= 8.0) reserves the right to kill your app when running in the background unless there's a foreground toast bound (even then, can still be killed in low memory situations). How does this solution work around that? Is there a need to opt into the legacy "battery saver disabled" mode for the app which more closely mirrors <= 7.0 execution model?

Most distributors both show a foreground notification at all times and require exempting them from battery optimization. Because of its efficient design, something like ntfy only uses a few percent of battery per day [1].

System-level integration into Android ROMs would eliminate the need for those things.

[1] https://docs.ntfy.sh/faq/?h=battery#how-much-battery-does-th...

Re: UnifiedPush: A decentralized, open-source push notification protocol

#59
post #34
post #2

Wow, 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…

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

Re: UnifiedPush: A decentralized, open-source push notification protocol

#60
post #54
post #34

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…

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.
Post reply on HN