Re: [w3c/push-api] Push subscription endpoint autodiscovery in HTML page: rel="alternate" type="urn:ietf:params:push" (#299)

> One solution would be something like a `onrequestpushsubscribe` event. It's important that the developer has control of calling subscribe() - after all, they'll have to send the subscription information to their server.

Sounds good, just not sure what would happen when the intercepted subscription request is rejected in term of user expectation and from an UI point of view.

Regarding concrete use cases, people could subscribe and receive Push notifications only for a specific GitHub issue or for a Chromium ticket simply by clicking on a Push subscription button, on a per page basis (without having to wait for a popup to appear).

Concretely, if there were a Push subscription button for a GitHub pull request, there would be several channels, like channels for "commits", "comments", "reviews" ; then the user could subscribe to "comments" and "reviews" for example.

```html
<link rel='push' href='urn:push:topic:github:pr' title='All activities for that Pull Request'>
<link rel='push' href='urn:push:topic:github:commits' title='Commits for that Pull Request'>
<link rel='push' href='urn:push:topic:github:comments' title='Comments for that Pull Request'>
<link rel='push' href='urn:push:topic:github:reviews' title='Reviews for that Pull Request'>
```

But the current Push model works on a per domain basis, also there's no relation between a specific URI and a subscription "topic", and it's up to developers to create their own subscription model.

So, perhaps, to facilitate subscriptions management, there could a way to register one or several "topic"/"channel" on a per URI basis. That way, the browser could then present several channels to subscribe to, similarly to the way Firefox displays multiple feeds for a page. The `<link rel='push'>` tag would be merely declarative with only a "mechanical" relation with the Push API, i.e. only channels registered by the `PushManager` would be handled, others would be rejected when the user clicks on them.

Also, not sure how a "channel" could be bound to a "topic" as defined by [RFC 8030](https://tools.ietf.org/html/rfc8030#section-5.4):

>    A push message topic is a string carried in a Topic header field.  A
>    topic is used to correlate push messages sent to the same
>    subscription and does not convey any other semantics.

Anyway, I believe there's something to think over, perhaps for a next generation Push API. Or something to code during a hackathon :smiley:.

At last, wondering about WebExtension, can one access the `PushManager` somehow ? I'd guess it'd be sandboxed. Could a WebExtension access to Push subscriptions or could it only display a button based on the page `<head/>` parsing ?

_P.S: The idea of Push subscriptions channels is inspired by [XEP-0060: XMPP Publish-Subscribe](https://xmpp.org/extensions/xep-0060.html)._

-- 
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/299#issuecomment-418966457