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

41–50 of 150 posts

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

#41

Post by kevincox »

karmanyaahm wrote: post #28
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 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 uses which do need encryption to forget to turn it on or accidentally turn it off.

For many apps the benefit here is indeed tiny, but so is the cost. So I think it is best to not support unencrypted messages altogether.

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

#42

Post by binwiederhier »

Andrew_nenakhov wrote: post #39

Oh gosh, a wheel reinvented again? XMPP did it ~7 years ago [0] and we have used it for quite a few applications already. [0]: https://xmpp.org/extensions/xep-0357.html

Please be nice. You can convey your information without the snarky tone. You may be factually correct, but your comment comes across quite rude.

From the HN guidelines [1]:

> Be kind. Don't be snarky. Have curious conversation; don't cross-examine. Please don't fulminate. Please don't sneer, including at the rest of the community. Edit out swipes.

[1] https://news.ycombinator.com/newsguidelines.html

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

#43

Post by kirimita »

Andrew_nenakhov wrote: post #39

Oh gosh, a wheel reinvented again? XMPP did it ~7 years ago [0] and we have used it for quite a few applications already. [0]: https://xmpp.org/extensions/xep-0357.html

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.

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

#44

Post by kevincox »

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?

WebSub + RSS/Atom is a good option for relatively slowly changing data. (Maybe at most a couple of times an hour). It is nice because it is opt-in and an enhancement on the regular polling API.

Using WebSub or UnifiedPush would technically very similar but you need a way for the client to pass you the subscription information. WebSub has a standard discovery process to manage this.

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

#45

Post by Andrew_nenakhov »

kirimita wrote: post #43
Andrew_nenakhov wrote: post #39

Oh gosh, a wheel reinvented again? XMPP did it ~7 years ago [0] and we have used it for quite a few applications already. [0]: https://xmpp.org/extensions/xep-0357.html

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.

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

#47

Post by nightpool »

karmanyaahm wrote: post #28
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 r…

> However, some protocols only send a wake-up ping or random ID in the push notification, Trifa and Matrix respectively

While I understand that some developers may think of security as wasteful, having unencrypted data be the default relies on every developer to spend much more time considering the possible threat models and how . Case in point here is Matrix—the IDs they send aren't random at all, they actually send full room IDs and event IDs for each message, so you'd be able to build up someone's entire social graph just from reading their unencrypted push notification data and looking up room IDs on the Matrix server in question or even correlating room IDs across different Element installs. This also hurts users, since they're not in a position to inspect the source code and understand how or whether they need to trust their "push provider" with whatever data the app developers might have chosen to regard as "less sensitive"—WebPush's encryption-by-default design removes trust from the equation entirely and prevents of these sorts of "passive surveillance" attacks (except those based on timing or message length)

> You can then decrypt these notifications in the app

This pushes all of the complexity of supporting encryption onto the app developer, instead of having it be provided by the platform where it can be centrally audited and securely managed.

> 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).

Why not do this innovation in an open standards body like the IESG where other stakeholders can give feedback and review? The web push standard does allow for Push Servers to use other custom wire protocols besides the default RFC8030, but having open and standards-based discussion of the possible performance improvements would "lift all boats" in terms of being able to provide low-power devices with timely push notifications

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

#48

Post by rgovostes »

binwiederhier wrote: post #40
rgovostes wrote: post #37

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…

ntfy [1] would work for you entirely in the LAN, if you self-host the server and the phones are connected to the same Wifi. It'll only work for Android phones though, since iOS forces APNS for push notifications. ntfy is also a distributor for UnifiedPush, so you're not entirely off topic here. Hehe. Disclaimer: I am the maintainer of ntfy. [1] https://github.com/binwiederhier/ntfy

Interesting thanks. Have you looked into Apple's Local Push Connectivity API? It's specifically designed for VoIP calls and text messages, but perhaps the latter is enough. Not sure if it requires you to bake in any keys at compile time, or if the iOS app could allow the end-user to configure the push server.

https://developer.apple.com/documentation/networkextension/l...

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

#49

Post by kirimita »

Andrew_nenakhov wrote: post #45
kirimita wrote: post #43

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.

> You only need to create a dispatcher app that will relay the notifications to third party apps.

That part is what specify UnifiedPush. It does not specify the communication between the push server and the distributor.

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

#50

Post by jacob019 »

londons_explore wrote: post #22
MayeulC wrote: post #8

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.

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