UnifiedPush: A decentralized, open-source push notification protocol (2022) | Hacker News Reader

UnifiedPush: A decentralized, open-source push notification protocol (2022)

f-droid.org

35 pointswhereistimbo15 comments

Whilst this is theoretically a nice idea for security/privacy, wouldn’t there be throughput/latency concerns over mobile networks if you aren’t just connecting to one server and getting all your notifications in one go? One of the biggest slow downs on mobile data is the initial handshake, so repeating that for each of your apps doesn’t seem worth the trade off to me.

This is the goal, in the same way Google does for FCM: the Play Services maintain a connection with their servers to get the notifications and then send them to the different apps. Here's it's the same with a server you control and know it won't read whatever is in that notification, without draining the battery because there's only the Unified Push app maintaining the connection.

> know it won't read whatever is in that notification,

Aren't notification contents E2E? The website is rather light on details.

IIUC notification contents are application-defined. So if you're building a weather app and don't care about encryption, your content can literally be "It's going to be sunny." Signal, on the other hand, would only send "please refresh" and then it's the app's responsibility to act on it.

Notifications don't appear to be E2EEed. They are encrypted in flight. But they do change formats while on the servers. For example, the application server contacts the push server using Web Push (like a webhook), but the communication from push server to the distributor app on the end device is using some other protocol like XMPP, Server send events or WebSockets. This obviously requires decryption.

But the encryption shouldn't be a big issue as @morith pointed out. The application server can send a notification to the end user application simply asking it to refresh. The second image on their home page (https://unifiedpush.org/) illustrates this.

Yeah, existing proprietary (e.g. Apple/Google) push notifications are not E2EE, so apps that need to convey sensitive information (secure messaging apps, etc.) tend to take this approach already regardless of push provider.

Related. Others?

Conversations (XMPP Client) is now a UnifiedPush distributor - https://news.ycombinator.com/item?id=34381598 - Jan 2023 (30 comments)

UnifiedPush: A decentralized, open-source push notification protocol - https://news.ycombinator.com/item?id=34094497 - Dec 2022 (146 comments)

A pity that iOS doesn't support UnifiedPush and probably won't in the foreseeable future[1].

[1] https://unifiedpush.org/users/faq/#will-unifiedpush-ever-wor...

This essentially kills it's utility for a lot of use cases.

Does it? If you're using an iPhone are you really expecting to be able to use a third party project like this for notificatioms with how locked down IOS is and Apple's limitations on what is allowed to be installed on your device?

You just reiterated my point --- and expounded on why it would be more accurately called "DroidPush".

this whole mess could be solved by mobile network operators giving every device a static IPv6, which the services can directly send packets to.

you know, just how the Internet Protocol was originally intended.

I would love for RocketChat to support UnifiedPush. It seems like such good fit.

Isn’t ntfy run purely best-effort for free by one person as a hobby?

There is paid plans for extra message limits and other features: https://ntfy.sh/#pricing

Reply on news.ycombinator.com