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 protocol are end-to-end encrypted, there's no concern about "trusting" the distributing server like there seems to be in this protocol (based on https://unifiedpush.org/spec/server/)
UnifiedPush: A decentralized, open-source push notification protocol
11–20 of 150 posts
Re: UnifiedPush: A decentralized, open-source push notification protocol
#12Wow, 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…
Does the user require to install a separate app to receive UnifiedPush messages?
Re: UnifiedPush: A decentralized, open-source push notification protocol
#13Why 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 isn't just for notifications to clients themselves, this would handle the federation of notification's.
Similar to how Apples push notification service works already (APN: https://en.wikipedia.org/wiki/Apple_Push_Notification_servic...)
Re: UnifiedPush: A decentralized, open-source push notification protocol
#14Why 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 isn't just for notifications to clients themselves, this would handle the federation of notification's. Similar to how Apples push notification service works already (APN: https://en.wikipedia.org/wiki/Apple_Push_Notification_servic... )
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.
Re: UnifiedPush: A decentralized, open-source push notification protocol
#15I wish we could extend SMTP to support notifications as self-expiring emails
Re: UnifiedPush: A decentralized, open-source push notification protocol
#16Wow, 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…
Does the user require to install a separate app to receive UnifiedPush messages?
Yes, they need to have a UnifiedPush distributor on their device, that acts like Google services.
OS makers could install a default UnifiedPush distributor though.
Lastly, the Embedded FCM UnifiedPush library (to be embeded into a client app) handles UnifiedPush over FCM (Google-provided push notifications), so that a server only has to handle the UnifiedPush API (with a rewrite proxy for UP->FCM).
Re: UnifiedPush: A decentralized, open-source push notification protocol
#17>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 periodically wake up for a short period and allow apps to service their connections
For this to work, you need apps to somehow conform to a standard timing and respond to a signal that says "hey, the OS is awake for you to do network things". Now each developer needs to implement some special code that understands the situation. After a while, all the devs start using libSleepyNetwork because getting those details right is hard. The libSleepyNetwork people realize that they can use a system daemon to further coalesce work for greater efficiency (one event loop is better than N event loops), so now all the consumer program C APIs are now backed by IPCs to the daemon.
This is exactly what's already happened on Android, except libSleepyNetwork is implemented by either Google, or these people. I don't think it's bad OS design at all. It's chasing efficiency via abstraction that encapsulates some complex coordination.
Re: UnifiedPush: A decentralized, open-source push notification protocol
#18>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…
> 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.)
The protocol does not specify how the distributor and push server communicate or keep a connection going. It's up to them to define an energy efficient way to do that. For ntfy [1], a single WebSocket or JSON stream connection is used to deliver messages to the device. This is very energy efficient and consumes As for regular wakeups (for polling), Android does not allow periodic work to be done more frequently than every 15 minutes, which is obviously not frequent enough to be useful.
> It's kind of a bummer to see bad OS architecture feed into over-complicated protocol/application design.
This is somewhat true. The restrictive Android eco-system is what led to the creation of UnifiedPush, but it's far from complicated IMHO
Disclaimer: I am the maintainer of ntfy [1], one of the UnifiedPush distributors.
[1] https://ntfy.sh
Re: UnifiedPush: A decentralized, open-source push notification protocol
#19The 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?
Re: UnifiedPush: A decentralized, open-source push notification protocol
#20Earlier quoted context omitted.
This isn't just for notifications to clients themselves, this would handle the federation of notification's. Similar to how Apples push notification service works already (APN: https://en.wikipedia.org/wiki/Apple_Push_Notification_servic... )
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 interacting with the client for the latter that’s running on your phone.
It looks like the submission side of UnifiedPush could indeed have been Web Push-compatible but isn’t, though.