5 ms·

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

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/ 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/ https://unifiedpush.org/spec/server/)

dijit 4y ago
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_service https://en.wikipedia.org/wiki/Apple_Push_Notification_servic...)
- nightpool 4y ago
  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.
  - mananaysiempre 4y ago
    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.
    - MayeulC 4y ago
      > 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 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.
    - nightpool 4y ago
      > 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 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.
emersion 4y ago
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.
karmanyaahm 4y ago
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 https://github.com/UnifiedPush/dart-webpush-encryption
- kevincox 4y ago
  > 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.
  - karmanyaahm 4y ago
    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-notifications.html https://volkerkrause.eu/2022/11/12/kde-unifiedpush-push-noti... [2] https://github.com/UnifiedPush/wishlist/issues/15 https://github.com/UnifiedPush/wishlist/issues/15

dijit 4y ago

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_service https://en.wikipedia.org/wiki/Apple_Push_Notification_servic...)

nightpool 4y ago
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.
- mananaysiempre 4y ago
  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.
  - MayeulC 4y ago
    > 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 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.
  - nightpool 4y ago
    > 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 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.

emersion 4y ago

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.

karmanyaahm 4y ago

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 https://github.com/UnifiedPush/dart-webpush-encryption

kevincox 4y ago
> 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.
- karmanyaahm 4y ago
  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-notifications.html https://volkerkrause.eu/2022/11/12/kde-unifiedpush-push-noti... [2] https://github.com/UnifiedPush/wishlist/issues/15 https://github.com/UnifiedPush/wishlist/issues/15