Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

UnifiedPush: A decentralized, open-source push notification protocol

f-droid.org

Post reply on HN
Print view View original

21–30 of 150 posts

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

#21

Post by MayeulC »

afandian wrote: post #19

The headline got my attention. I'm looking for a standard for subscribeable notifications / callbacks to update users of data changes in an API. Bonus point for federated. But server to server, not server to client. Double bonus points for connecting to consumer services like Zapier or IFTTT. I'm planning to use WebSub and/or RSS, but on the look out for others. Any pointers?

That use-case sounds a bit similar to Webmentions: https://en.wikipedia.org/wiki/Webmention

See also... The See also section in that article :)

You say it would be server to server, but are both publicly reachable?

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

#22

Post by londons_explore »

MayeulC wrote: post #8
notwokeno wrote: post #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 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.

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 particularly expensive, so might as well run them all at once (they tend not to be CPU bound - often much of the wakeup handler is spent waiting for the network to connect and send a packet or an ack to arrive back).

This turned out to be a very very bad idea. All it takes is some app to have a 'wake up exactly on the hour', and now all other app callbacks will also run exactly on the hour. End result: Mobile networks get 10 million phones all waking up within a few milliseconds of one another, and everyone wanting to connect, and the whole mobile network fails because it was never designed to have 10 million phones all trying to connect within a few milliseconds.

That idea was scrapped.

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

#23

Post by jrmg »

notwokeno wrote: post #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 i…

Even if this were all synchronized, you’d still need to have all the apps memory state available - either taking up loads of RAM or requiring a lot of expensive paging.

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

#24

Post by MayeulC »

seydor wrote: post #15

I wish we could extend SMTP to support notifications as self-expiring emails

It would also be nice to extend IMAP to support UnifiedPush...

The use-case would be new mail notifications; it wouldn't be too hard to do, and would be quite useful, as I typically have multiple e-mail accounts.

You could however build a UnifiedPush-compliant SMTP-based or IMAP-based distributor.

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

#25

Post by lern_too_spel »

MayeulC wrote: 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…

Congrats! It's always surprised me that Amazon or one of the other Android vendors didn't do this themselves to make porting to FireOS or other services-included Android distributions easier, but I hope you get funding from them for doing their job for them.

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

#26

Post by emersion »

nightpool wrote: post #11

Why use a new custom-built protocol instead of adding support for the Web Push protocol already supported by Firefox, Chrome, Safari and others? https://web.dev/push-notifications-web-push-protocol/ . Now backend developers have Yet Another Push Notifications Protocol to build support for, instead of being able to just easily plug into their existing code. As a benefit, since all notifications through the Web Push pr…

This is partially explained in the blog post.

I'm personally using UnifiedPush HTTP endpoints as-if they were Web Push, and it just works. I handle decryption manually on the receiving end.

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

#27

Post by MayeulC »

mananaysiempre wrote: post #20
nightpool wrote: post #14

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…

> It looks like the submission side of UnifiedPush could indeed have been Web Push-compatible but isn’t, though.

Exactly. It was discussed a bit early on whether to mandate encryption, but simplicity was chosen instead.

Adjusting the server protocol to make it compatible with WebPush is also being discussed: https://github.com/UnifiedPush/wishlist/issues/15

That would be useful for supporting Telegram, for instance. I don't really see it becoming mandatory, however.

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

#28

Post by karmanyaahm »

nightpool wrote: post #11

Why use a new custom-built protocol instead of adding support for the Web Push protocol already supported by Firefox, Chrome, Safari and others? https://web.dev/push-notifications-web-push-protocol/ . Now backend developers have Yet Another Push Notifications Protocol to build support for, instead of being able to just easily plug into their existing code. As a benefit, since all notifications through the Web Push pr…

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 respectively. There, encryption is unnecessary complexity.

However, we don't use the WebPush API between the push server and distributor since there is a lot of scope for innovation in that space (for example Google's FCM uses a custom XMPP based protocol).

[1] One example, https://github.com/UnifiedPush/dart-webpush-encryption

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

#29

Post by londons_explore »

MayeulC wrote: post #8
notwokeno wrote: post #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 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.

> 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 know if a connection is still alive. You need to send actual data and have the application respond.

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

#30

Post by karmanyaahm »

MayeulC wrote: post #24
seydor wrote: post #15

I wish we could extend SMTP to support notifications as self-expiring emails

It would also be nice to extend IMAP to support UnifiedPush... The use-case would be new mail notifications; it wouldn't be too hard to do, and would be quite useful, as I typically have multiple e-mail accounts. You could however build a UnifiedPush-compliant SMTP-based or IMAP-based distributor.

JMAP has a push implementation I really like, and it's natively compatible with UnifiedPush. Would be nice to see more adoption there.

https://jmap.io/spec-core.html#push

Post reply on HN