Hacker News new | past | comments | ask | show | jobs | submit login

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.




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


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




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: