[Proposal] Media Feeds API


We propose a new API to allow a user agent to discover a media feed provided by a website. When fetched by the user agent the site will return a feed of personalized media recommendations for the user.

This is an interesting proposal. What would be the interaction between this and the Media Session API? Would both make use of the same native UI mechanisms?

The Media Session API focuses on metadata for the currently playing audio/video on an open tab.

The Media Feeds API is a background fetch for recommendations that the user agent can present to a user. The user has to have visited the site before for the feed to be discovered but the site does not have to be open for the browser to do the fetch.

At the moment, we (Chrome) are planning to use something like this to collect data so that we can build native UI surfaces on top of that data in the future.

Interesting proposal @beccahughes, but I’m left wondering a couple of things that maybe you can help me understand a bit more:

  • why surface this at the browser level, instead of just letting the web page handle it via fetch() or whatever?
  • why do this at the web manifest level instead of, say, using a <link rel>?

For manifest inclusion, the timing might be a bit wonky for the request… like the user might not have logged in yet when the manifest is read, for instance… so this feels like it might be better suited to something inside a tag? … I don’t know tho, just speaking out loud here :slight_smile:

1 Like


  1. This is at the browser level because the web page is never meant to fetch the feed. The browser will choose which feeds are relevant to fetch and fetch those. We do this in the background and the web page is unaware of it.

  2. Using a web manifest provides a mechanism for the site to remove the feed in the future by removing it from the manifest

For the timing, if we see the feed before the user has logged in then the site should return a generic or empty feed. When the user logs in the browser will see the cookies have changed and re-fetch the feed.

Thanks for the clarifications. I’m bit worried about 2, to be honest, because we haven’t really worked out how updating web manifests works. I guess maybe this might force us to do that, but please be aware that updating the manifest is currently undefined behavior.

I’m not sure to understand the differences between having a new media_feed_url in the web manifest and a potential new link rel tag.

At first sight, it seems like the latter is better as it doesn’t force a website to define all other mandatory keys in a web manifest.

Moreover, “removing a media feed” could be configured as returning a 410 HTTP “Gone” error for instance.

When Becca and I talked about this, my suggestion was to go with Manifest only because my rule of thumb for Manifest vs link rel tag is whether the value would be expected to be the same on every page of a given website. In other word, is this a site-level information or a page-level information. In this case, it would be a site-level information.

How would this work for websites that allow users to have multiple profiles (Netflix for instance)?

Having one single media_feed_url in a web app manifest doesn’t seem to fit this use case. A link rel tag can be unique to a user profile and can be provided at a page-level.