Alternative discovery mechanism

[Gregoor]

Hi there,

I much appreciate the spec! Now I am wondering (and do let me know if this is an old discussion), if there is interest in an extension which would allow for a site-wide discovery mechanism. I.e. from what I can tell currently a provider can either

1. list themselves in the registry or
2. put a link-tag on the specific site which should be embeded.

Now for my use case both are not feasible paths, because

1. I am looking at a federated roaster of domains which rotate a lot, so registering them is too manual of a process.
2. I want to know about embed-ability from a CORS-secured context, where I can not request (and for size reasons, also don't want to) it on a per-URL basis.

So I was wondering if there would be interest in a spec extension for exposing sth similar to the providers/manifest.yml on a top-level (in a possibly CORS friendly way)?

I'm not entirely sure yet how it'd look like, I guess the simplest version would be to serve a oembed.json on the root. I understand this is not the most backwards-compatible way, since it also infringes on web developers freedom to use all their routes to their liking.
Then again with sitemap.xml or robots.txt, there is some precedence for hardcoded files, so it might actually be fine?

[bdougherty]

What about using a Well-Known URI? So it would always be http://provider.com/.well-known/oembed?url=http://provider.com/123 (or whichever other name, but I see no reason to use anything other than oembed). It could either return the response directly or redirect to the appropriate url instead.

I think this would be a great thing, but unfortunately it would probably be very difficult to get every provider to support it.

[Gregoor]

That's a neat idea. I'd like that too!

Wrt getting providers to adopt it: I hope oembed becomes important enough at some point that providers will WANT to support it, and I think it'd be great if it would not depend on a centralized directory anymore at that point.

[CanRau]

Really like the /.well-known idea, I understand that not all providers will support this soonish or ever, though it'd be very handy to be able to just try a "fixed" url instead of having to scrape the html, parse response header or fetching and checking the provider list (which not necessarily is complete/up-to-date)

Instead I could try the well-known path and if that doesn't work scrape html also potentially for other meta tags, which I always wondered why do I need to parse HTML for all the meta tags, but it is what it is 😅
So anyway, .well-known/oembed could be a step in a less scrapy future 😇

Apart from the well-known option I'd also be open for just /oembed, that's what I'm using right now annyway 🤓

[danbars]

How about returning this as a header?
The header can be supported in both GET and HEAD requests which should support CORS in order to make it readable from the browser.
So if I want to know if some URL supports oembed, I'll make a cors HEAD request, and look for X-Oembed header which will contain the oembed URL for that resource.
The downside is that since this is a cors request, there will be a preflight request, but it probably doesn't matter that much.

[CanRau]

What'd be the benefit over /.well-known/oembed or just /oembed? 🤔
Just curious

[danbars]

It allows flexibility in implementation.
For example, I may have a single oembed endpoint deployed in oembed.acme.com, while I have multiple resources deployed at service1.acme.com, acme.com/resource2, etc

Also in some cases you don't have control over the top-level of the server, so it'd be hard to implement the well-known option

I think that when talking about a standard that needs to work in many different platforms and environments, we need to make as fewer assumptions as possible in regards to the considerations that people may have about implementation

[CanRau]

Interesting, yea, good points, seems more flexible 👌