[Iframely] - open-source self-hosted embed gateway

277 views
Skip to first unread message

Ivan Paramonau

unread,
Jun 18, 2013, 1:38:53 PM6/18/13
to oem...@googlegroups.com
Hi everyone, 

As announced a little earlier, we've open-sourced self-hosted embed gateway. 
It is now available on GitHub: https://github.com/itteco/iframely

The server is capable of detecting oembed, open-graph and twitter-cards embed data, unifies some meta as generic features, and also has over 70 (so far) custom domain plugins. 

It's a Node.js package, but can be used from other platforms via api. 
We re-factored our previous architecture to make this one more powerful and extensible, and so we are back to 'beta' status. 

Feedback and contributions are appreciated. 


Thanks,
Ivan.

Tim Ansell

unread,
Jun 18, 2013, 9:02:07 PM6/18/13
to oem...@googlegroups.com
Any chance you could support the Embedly API? I'd love to use your stuff but don't really have time to convert my code :/

Tim


--
You received this message because you are subscribed to the Google Groups "OEmbed" group.
To unsubscribe from this group and stop receiving emails from it, send an email to oembed+un...@googlegroups.com.
To post to this group, send email to oem...@googlegroups.com.
Visit this group at http://groups.google.com/group/oembed.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

Ivan Paramonau

unread,
Jun 18, 2013, 10:31:49 PM6/18/13
to oem...@googlegroups.com
Sorry Tim, the API mimics the list of <link> elements with the attributes, and returns it as JSON. Like:

<link rel="player"            // use case
type="text/html"              // as iframe
href="//iframe.ly/234rds"     // src
media="min-width: 100"	      // sizes
title="Thanks for all the fish!" >

Unfortunately, the media-query part of API is not compatible with oEmbed spec, and so we can not convert it. 

The good news is that there is a client/jQuery javascript library included into the package, which should make the implementation easy.

Ivan.

Mathias Panzenböck

unread,
Jun 21, 2013, 9:20:26 AM6/21/13
to oem...@googlegroups.com
Interesting rel attribute value. Do you have any documentation about this? Is it used by anyone? I couldn't find it here: http://microformats.org/wiki/existing-rel-values

Ivan Paramonau

unread,
Jun 21, 2013, 9:49:34 AM6/21/13
to oem...@googlegroups.com
Rel attributes are not standard, yes. The good thing about them though is that you may have an array, like rel="oembed player". I think I saw similar approach discussed in this group before. 

The documentation is in the making under "oembed/2" name, the start is here: https://github.com/itteco/iframely#oembed2-quick-draft.
We reserve rels for use cases, and mime types for embed methods. We will specify use experience / tech aspects for all combinations, similar to the way Twitter lists requirements for their "player" cards. 

So far, nobody is publishing these links, but iframely package itself will start consuming very soon. Hopefully, it will drive some interest as there will be the distribution for it. iframe.ly - our simple web shortener - is under refactoring and will start publishing those links really soon too. We are in discussions with other publishers as well, but it's a chicken and egg for them, and they want to see the distribution first.  

Start using/contributing to iframely on github to help this process going :)

Mathias Panzenböck

unread,
Jun 22, 2013, 9:19:26 PM6/22/13
to oem...@googlegroups.com
Very interesting. I'd like to use this on both ends: parsing the link tag and generating it. But for what I would generate it, it wouldn't be an audio/video player. It would be an iframe based widget, though. Should I still (ab)use the player rel?

Ivan Paramonau

unread,
Jun 23, 2013, 10:38:40 PM6/23/13
to oem...@googlegroups.com
Welcome aboard :) 

It is expected that "player" use case will be consumed in media libraries/playlist etc, as we will also specify the playback/sync events via postMessage, similar to the ones YouTube/Vimeo/SoundCloud got already.

The spec will be constantly expanding though, as it is easier to add than it is to change. We start with the ones that are already available by publishers (logo, thumbnail, player, reader) and that we've verified a lot of implementations of and can document. 

If you'd like your use case to be included into initial version too, please, submit an issue to the repo and we'll discuss it there. We see various other scenarios as well, but it takes community to come up with exact use case. 

For now, "reader" will probably work well for you. Iframely returns "reader" for Twitter statuses, for example (and it will change when we have a better use case).
Reply all
Reply to author
Forward
0 new messages