Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Alternative discovery mechanism #676

Open
Gregoor opened this issue Nov 6, 2022 · 3 comments
Open

Alternative discovery mechanism #676

Gregoor opened this issue Nov 6, 2022 · 3 comments

Comments

@Gregoor
Copy link

Gregoor commented Nov 6, 2022

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
Copy link
Contributor

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
Copy link
Author

Gregoor commented May 22, 2023

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
Copy link

CanRau commented Sep 16, 2023

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 🤓

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants