Ideas & Suggestions for 23

plus, it'd allow me and most of my friends share 23 images on our primary social network.

well, plurk doesn't display flickr videos, so i'm guessing flickr's implementation is still images only, but i'm not sure.

basically, you provide the endpoint, and the service that wants to embed your stuff has to hook into that endpoint.

there are probably lists of providers, including in that documentation i linked to, that you'll want to get on so that consumers can know you exist and want to hook into your stuff.

anyway, like i said a bunch of us asked plurk what it would take to embed 23 photos based on photo page urls, like they to with flickr, and the response was "ask 23 to support oembed" - which i think is pretty reasonable - since the alternative is them making custom code for every single provider out there, instead of just hooking into an endpoint which is much easier.

I am loving the rapid response from 23. Customer service alone is selling me on the site (of course, it helps that it is also beautifully simple).

we just put a flickr photopage url into a plurk, like:

"shares http://www.flickr.com/photos/striatic/4109929941/ "

and plurk translates that to:

"shares "

except they browser shrink the image down a little until you click it, and insert a link to the photo page underneath the image when you click it to make it larger.

which makes it incredibly easy to share photos, especially from mobile devices. like if ping.fm shoots the link over, everything works properly and is nice and integrated.

no. other sites other than plurk can and do use oEmbed to embed images and video on their pages in the same way as plurk does.

here's an example of it working on plurk:

http://www.plurk.com/p/vbzmo

but other sites use it to convert youtube links into videos, and flickr links into images.

Alright guys; oembed is now supported!

(There's are meta tags on individual photos and the oembed endpoint is http://www.23hq.com/23/oembed. However, it doesn't seem to be enough for plurk just to have a implement the protocol?)

Let us know how it turns out... (also, if you do talk to them, ask them about their discovery mechanism for oembed. Are they only doing it for whitelisted domains, or are they looking up across domains using the discovery standard?)

There's some confusion in the spec on whether to use <url>/<height>/<width> or <thumbnail_url>/<thumbnail_height>/<thumbnail_width> for the photo type (in fact, it specifies that the first combination *must* be present for photos, and that the latter *must* be present in there's a maxwidth or a maxheight patameter) -- so I opted for including both variation. Just to make sure we don't clash with any existing implementations.

yay! plurk just sent me a message that 23 is now supported, but won't make it to the site until the next rollout.

no. haven't asked about their discovery mechanism.

are you thinking it could be used to embed slideshows and stuff?

at some point you might want to contact them directly.

anyway, i'm sure we will let you know when the feature is live : ]

regarding returning the thumbnail element:

Seems at 23, you are now returning this element, but it is always the same value as the url element? I realize you can request with different maxheight & maxwidth params to determine the size of the media described... but seems if you are gonna include the "optional" thumbnail element, it should reflect something that is actually a smaller version?

I don't know if this is what tripped plurk up or not, but it does seem a little inconsistent? Just for reference, Flickr's oEmbed implementation simply ignores the thumbnail element since you can ask for that with a request defining your max dimensions.

PS - I knew you had posted about that above. Sorry I didn't look harder, but it still feels counter to the intent of the thumbnail element. For video... a thumbnail might be an img representation at the same dimensions... but for photo it would seem to want to be the smaller variety.

I also think, and this isn't even really discussed in the goals of the spec, but it might behoove photo sharing sites to offer meta discovery via oEmbed when the static resource URLS are provided. Think of it as a static reverse lookup of sorts. This could come into play when considering the highly contested hotlinking debate/problem.

For example. For giggles, I could write a GM script or FF Extension that discovered when hotlinked images are originating from 23, and do some extra bits and bobs (via oEmbed calls) to display author and kosher linkback info to the user.

This might require a secondary scheme/endpoint at 23. But it is the type of thing I think about when I think about the possibilities with oEmbed.

Edit to add: Since discovery (via rel=alternate) is completely optional... it would be valid within the spec as far as I can tell. Hard to put a rel link in a image resource anyhoo. Though more RESTful discovery could have perhaps better managed this aspect.

Edit to add caveat: Sharing/hot-linking private statics is no doubt allowed... but oEmbed discovery of meta info should not be valid for static urls that are private content.

Even hard coded endpoints for statics would still be a step forward I think. There was some interesting discussion of these flaws with oEmbed here.

Flickr's implementation was responsive to maxwidth/maxheight when I tested it. And the way I read the "photos" section of the spec:

2.3.4.1. The photo type (required elements)
type, version, url
width, height (responsive to max in request)

Everything else I read as "nice" and "optional" (including the discovery bits)... if thumbnail_url, thumbnail_width, and thumbnail_height are included: they need only also honor the requested maxwidth/maxheight. That is to say you cannot return a thumbnail LARGER than the requested boundary... but it can be any size otherwise.

Edit to add: Specifically, this statement in your earlier comment I don't think is what the spec says about thumbnails. Just that they honor maxwidth/height when that is present.

(in fact, it specifies that the first combination *must* be present for photos, and that the latter *must* be present in there's a maxwidth or a maxheight patameter)

So yes, your "same size" results are not invalid per say. But also provide no benefit (such as avoiding a second request to get a image resource more suitable for a preview).

But admittedly, I could be vastly misinterpreting something. On the discovery subject. Even flickr isn't including the recommended rel=alternate that I can tell, at least not on the photo pages themselves.

i just heard back from plurk again, and they've said that while they have still not rolled out oembed suport, they will let me know when they do.

so the short links will work eventually, just not yet.