Re: [w3c/push-api] Retry push event (#300)

> [W]e receive a push event without payload and then we download the pending notifications from the application server. This was the only method available in 2015 when we started developing Pushpad.xyz and I think that many other services do the same: now in our database we have millions of subscriptions that have an endpoint but not the keys to encrypt a payload (because we don't use that).

Please consider thinking about an upgrade path. Including the payload with the push message itself is a much better and more reliable experience for users. One idea to quickly source keying material could be to upload the keys with your analytics ping when receiving a message, or when the user next visits the website.

> This method is the original method suggested by the Push API, it is compatible with all the current browsers and works well: so I hope you won't break this in the future. Finally I would like to mention that this method doesn't increase the bandwidth usage since we would have to send a request to the server in any case to track the delivery.

There certainly are use-cases for push messages that don't carry a payload. They come with two downsides: lack of sender authentication (by not being able to validate the keying material) and reduced reliability if more data has to be fetched from the network.

Introducing additional fetches definitely increases bandwidth as a full connection has to be established; RFC8030 includes a message receipt mechanism for acknowledgements, and many of the other push services provide similar functionality. Also something to consider is that push services are _really_ good at delivering messages, even in networking conditions where other fetches might not go through.

> For the above reasons I think that it would be useful to apply that retry mechanism not only to the showNotification resources (like icon)

Note that at least two implementations handle this by omitting the resources that can't be loaded rather than trying to fetch them again.

> Finally you can use the Notification tag to avoid duplicates: so I don't see any drawback.

Unfortunately the availability of such functionality doesn't mean that it's Web compatible - if existing users of the Push API don't include a `tag` already, users are still going to be exposed to the negative effects.

> when an exception occurs inside the push event, you can simply avoid to acknowledge the reception of the push message to the push service, so that the delivery will be retried after some time.

The push messaging functionality might not be provided by the browser itself; several implementations will be limited by operating system constraints here.

> That may conflict with userVisibleOnly... I don't know if showing a notification in the sync event (and not inside the push event) will be considered a notification displayed by the browser.

Yeah, that is unlikely to work. The purpose of `userVisibleOnly` is to ensure that users are aware of _why_ their device is doing work in the background.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/push-api/issues/300#issuecomment-418451218