Push subscription endpoint autodiscovery in HTML page: rel="alternate" type="urn:ietf:params:push"

[kael]

RFC 8030 - Generic Event Delivery Using HTTP Push states that:

This document intentionally does not describe how a push service is
discovered. Discovery of push services is left for future efforts,
if it turns out to be necessary at all. User agents are expected to
be configured with a URL for a push service.

Is there any plan to add some autodiscovery mechanism in HTML <head/>, perhaps something like <link rel="alternate" type="urn:ietf:params:push"> ?

[beverloo]

There are no plans in adding such machinery.

We decided against the bring-your-own-push-service model because it would negate a lot of the resource usage reductions enabled by the Push API. As far as I'm aware, none of the current implementations provides users with an option to change push service either, which would be a prerequisite to developing a discovery mechanism. This is captured in the Security and Privacy Considerations in the specification.

[kael]

Not sure we're talking about the same thing.

I was thinking to HTML autodiscovery mechanisms:

<!-- ATOM/RSS -->
<link rel="alternate" type="application/atom+xml">
<link rel="alternate" type="application/rdf+xml">
<link rel="alternate" type="application/rss+xml">

<!-- OpenSearch -->
<link rel="search" type="application/opensearchdescription+xml">

<!-- PWA -->
<link rel="manifest">

<!-- PuSH - https://pubsubhubbub.github.io/PubSubHubbub/pubsubhubbub-core-0.4.html -->
<link rel="hub">

<!-- Salmon Protocol - http://www.salmon-protocol.org/salmon-protocol-summary -->
<link rel="salmon">

<!-- Webmention - https://www.w3.org/TR/webmention -->
<link rel="webmention" />

<!-- GitHub WebSocket (dunno what it does) -->
<link rel="web-socket" href="wss://live.github.com/_sockets/*">

So I was thinking to a similar mechanism for Push autodiscovery. It would "logically" replace the RSS icon, well at least theoretically.

The current way to discover the Push service with the popup is not perhaps the best approach from a UX perspective.

For example, Firefox keeps pop'ing up notifications subscriptions request despite I had previously clicked on "Never", and although it's a matter of implementation, it's really annoying.

Having an HTML autodiscovery mechanism could be an alternate way to engage users in Push subscriptions, or at least a pre-step.

I'm not sure I see the big picture, mainly thinking the thing from a user point of view, and had the idea while scrapping some HTML pages metadata. But perhaps there could be something to think deeper.

[linabutler]

Hi @kael! 👋 I think I understand what you're asking (please let me know if I've misunderstood), but we aren't planning to let sites specify their own push server.

One of the advantages of push is that the browser, or the device, only needs to maintain a single connection to receive messages. Supporting many push servers means the browser would need to maintain multiple persistent connections, one for each server. At that point, it would be more efficient for the site to open a WebSocket or EventSource stream to its own server, and bypass push completely.

Further, the browser and push service might use a different protocol; for example, Firefox uses JSON messages over a WebSocket, and I think FCM uses XMPP. In theory, RFC 8030 specifies this interface, too; in practice, I'm not sure if anyone implements it.

The current way to discover the Push service with the popup is not perhaps the best approach from a UX perspective.

For example, Firefox keeps pop'ing up notifications subscriptions request despite I had previously clicked on "Never", and although it's a matter of implementation, it's really annoying.

Ah, I see what you mean. "Push service discovery", in the spec, means "letting the browser connect to a different push server"...not "seeing if the site supports push," which I think is what you're asking about. (In fact, the permissions UI isn't related to the push server at all).

For Firefox specifically, you can block all notification requests by opening about:preferences#privacy, scrolling down to the "Permissions" section, clicking "Settings..." next to "Notifications", and checking "Block new requests asking to allow notifications".

But you're totally right that it's an implementation detail, and the spec doesn't (can't?) have an opinion on how a browser presents its permissions UI.

[kael]

I believe the correct thing would be <link rel='push'> though.

I'm not asking about using a push server alternate to the browser-vendor one, but for a simple way to advertise to the browser that there's an Push endpoint on the page.

Using <link re='alternate'> is incorrect though inspired from RSS semantic, but has more general and precise meaning, hence I believe the confusion.

If there were a <link rel='push'> meta tag, it would be up to the browser implementation to bind it to PushManager.subscribe().

It would (slightly?) modify the current Push model, as currently it's only up to the browser to initiate the Push subscription request (with some design considerations, like prompting for notification permission only at some point in the site/app), whereas with a Click & Subscribe to Push button the user could immediately subscribe to the Push service, without having to reach certain pages or events before subscribing to the Push endpoint.

Going further, there could be a notion of Push subscription channel, and that would be advertised like:

<link rel="push" href="urn:push:channel:blog">
<link rel="push" href="urn:push:channel:blog:comment">

with again something similar to RSS feeds displayed below the RSS button, but that's really far fetched at that point.

Anyway, I think having a way to advertise to the browser that there's Push endpoint available on the site, using an HTML meta tag, would be useful.

Something similar to PuSH in spirit, and functionally equivalent to <link rel="web-socket" href="wss://live.github.com/_sockets/*"> which actually sends WS messages like that one (FYI 😃):

{
 "'data": "['notification-changed:2463',{'aria_label':'You have unread notifications','ga_click':'Header, go to notifications, icon:unread','span_class':'mail-status unread'}]"
}

[beverloo]

Let's take a step back and focus on the what rather than the how :).

You'd like a mechanism for the site to indicate that they support push messaging, enabling more subtle UI to be presented by the user agent (such as an icon in the address bar, like RSS) so that users can opt-in by clicking on that icon, as an alternative to sites requesting permission at their own accord. Is that correct?

[kael]

Yes, that is correct. 👍

For the background, I'm working on extracting structured data from websites and noticed lots of interesting meta tags ; at one moment I started to think that it'd be nice to have "yet another HTML meta tag" to announce the availability of a Push endpoint.

So my request is "biased" by willing to get the information over an HTTP request. That's why I'm also mentioning the how. 😃

But I'm wondering how such a "Click & Subscribe Push" button would modify the current Push model, considering it'd break the design of some sites/apps, and if that modification could be tolerated.

Addendum: The flow of ideas went as this:
1. It'd be nice to have "yet another HTML meta tag" like <link rel='push">
2. With a new HTML tag, browsers could display the Push endpoint availability using an icon
3. With a new Push icon, users could directly subscribe to the Push endpoint (and also get an immediate visual display of the Push subscription status using the same icon), the "RSS-way"
4. But the HTML meta tag and the PushManager.subscribe() method are not necessarily bound, let's strongly suggest that the browser should bind the action of clicking on the Push subscription button to the call of PushManager.subscribe()
5. But it would break the current Push model, wouldn't it ?
6. Still, what about adding explicit Push channels subscriptions, the "RSS way"
7. That'd be awesome to be able to remotely subscribe to Push endpoint based on the HTML meta tag, but I guess for now I'll have to stick to using WebSub and maintaining a web server to handle WebHooks.

[kael]

Thinking a bit more to the thing.

"Automagically" binding a <link rel='push'> to the call of PushManager.subscribe() wouldn't break the current model though.

If a site/app wishes to keep control of the prompt notification, it wouldn't include the <link rel='push'>until a certain step, at which point <link rel='push'> can be dynamically added, and the icon displayed accordingly.

But in that case, for a "selective" display of the Push subscription icon, it'd require to query the Push subscription state each time the page is loaded and decide or not to add <link rel='push'> to the <head/>.

Also, for the case of a <link rel='push'> pointing to unhandled Push subscriptions, the browser should throw an error (I believe it would rarely happen in a day to day use).

Not sure it requires some changes in the API, and could already be working with a "smart" implementation. (Well, an Firefox extension like Semantic Radar could do the thing though, sounds like I could experiment if I found the time 🤔)

[beverloo]

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.

Before proceeding, however, we'll have to gauge whether there is interest in something like this from implementations.

Putting my Chrome hat on, this isn't something that we'd prioritize, primarily in favor of reducing permission spam and notification annoyance. UI surface would have to be provided by an extension, at least initially, which further reduces priority.

[kael]

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.

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

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

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.

[marcoscaceres]

Link relationships should ideally be defined in HTML - with hooks back to this spec, if needed.

I'm marking this a V2 for now.

[marcoscaceres]

Closing as won't fix.