Support for receiver-side browser push notifications.

[tcard]

We currently have server-side support for receiving push notifications in the browser as implemented in Firefox. We'd like to integrate this into the client-side API, following the push receiver spec as closely as possible.

We'd also need to make sure it works for Chrome, Safari and others. As of today, I've been using this little Go program to test device registration, channel subscription and receiving notifications, but it only works in Firefox. The current server-side implementation expects a targetUrl and an encryptionKey, both unique per device (browser), but this might need to be adapted too. (I hope not, since that's supposed to be a W3C standard.)

┆Issue is synchronized with this Jira Story by Unito

[tcard]

Missing:

• Ably's application server key is currently hardcoded. Probably needs to be served. https://github.com/ably/ably-js/blob/183a62dd7cb381262ad884677d126a966c8cb64e/browser/fragments/platform-browser.js#L77
• Safari support. See https://github.com/ably/wiki/issues/242 https://github.com/ably/ably-js/blob/183a62dd7cb381262ad884677d126a966c8cb64e/browser/fragments/platform-browser.js#L123
• Form factor needs to be detected. https://github.com/ably/ably-js/blob/183a62dd7cb381262ad884677d126a966c8cb64e/browser/fragments/platform-browser.js#L30
• Documentation for ClientOptions.pushServiceWorkerUrl, the argument passed to navigator.serviceWorker.register. For W3C push only.
• Push activation documentation for JS.
• Tests. See ably-java tests for inspiration.

[tcard]

Also, PushChannel is not implemented at all.

[jamienewcomb]

@Peter-Maguire when we move a ticket to blocked, can we remember to comment on the ticket stating the reason why please. We want to avoid this knowledge being stored with those who only attend the stand-ups.

See these internal docs https://ably.atlassian.net/wiki/spaces/DEL/pages/1789460495/Ticket+status+guidance+-+what+do+they+mean and https://ably.atlassian.net/wiki/spaces/PEO/pages/1489305654/Written-first+communication+at+Ably cc @deanna-lad

[Peter-Maguire]

Got it - this is blocked due to the backend web push API support not being complete. The backend requires a public/private ECDSA keypair to be generated, but browsers do not support exporting the keys in a format that the backend can understand. The general consensus seems to be that work on JS push would be better directed towards react-native, as there is more of a demand and already proven backend support for FCM/APN

[jamienewcomb]

@Peter-Maguire thank you

backend web push API support not being complete

Is this something we need the realtime team to fix and if so, has it been raised with them?

[paddybyers]

Web push needs to find its way into the relevant pod backlog, get scoped, prioritised, etc. There's multiple parts needed.

[jamienewcomb]

Yeah exactly. Peter was doing some initial work to see how complete the web push implementation was and if it actually works. The outcome is we are quite far off so if peter can elaborate on 'web push API support not being complete' in a ticket, then at least this will help the next team/pod who do pick this up

[jamienewcomb]

Hey everyone - pleased to say that 'Push notification support for web browser in ably-js lib' and 'React Native support for Push Notifications' are in development and should be released over the next 6-8 weeks. These are duplicate issues so I will close them.

cc @owenpearson