About OExchange

OExchangeDuh.

How cross-site sharing (mostly) works today…

A User…

Is browsing the web…



And decides to share something….


And decides to share something….so they click a button (or a menu) like this:

Or this:

Or this:

This button takes the URL of the current page:


http://www.example.com/something



And the service the user picked…



And the service the user picked…

And just sends the User’s browser to a URL specific to that service…

…like this:

http://www.facebook.com/share.php?u=http://www.example.com

Now the user is just interacting with that site to complete the share…

So basically those buttons just format requests to specific URLs for each site…


(oh, except for the tools that scrape, or encourage “the password anti-pattern”)

And it works like this for LOTs and LOTS of different services, which are all pretty close, but different.


http://www.facebook.com/sharer.php?u=http%3A%2F%2Fwww.example.com

/sharer.php?u={the url}

http://www.google.com/bookmarks/mark?op=add&bkmk=http%3A%2F%2Fwww.example.com

/mark?op=add&bkmk={the url}

http://www.stumbleupon.com/submit?url=http%3A%2F%2Fwww.example.com

/submit?url={the url}

http://www.myspace.com/Modules/PostTo/Pages/?u=http%3A%2F%2Fwww.example.com

/PostTo/Pages/?u={the url}

This is just silly

Link-sharing buttons and menus proliferate the web.

They are occupied with URL translations.

And they are not solving real user problems.

Sharing tools could do more interesting things, if the actual content exchange was less of an issue.

Like more advanced tracking for publishers, more advanced targeting for users, and larger service networks for everyone.

And the places a user is sharing to should control the interface/experience

And the places a user is sharing to should control the interface/experience

Sort of like how the providers control the experience in open authentication flows

The Open Stack is coming together…


For identity, access control, service discovery, contact data, application formats, and more…


For identity, access control, service discovery, contact data, application formats, and more…

But the simplest “share this basic piece of content to this other site” isn’t included

How it should be

• The simple process of sharing/posting/sending links (and more) should be standardized

• Sharing tools should focus on user value, not on proxying URL formats between sites

• Sharing increases with targeted and personalized choices for the user, minimal intermediate UI, and tighter tools (browser and page) integration

The Open Stack(Now with 100% more sharing)

Discovery XRD/S

Common Identity OpenID

Delegated Access OAuth

Sharing OExchange

People Portable Contacts

Applications Open Social

Simple, standard sharing

Why do we care?

Half a billion uniques.

A LOT of sharing.

What’s really needed?

Two different problems; defining the content, and defining a way to share the content. All we need is:

• Simple agreement on how to exchange typed content, replacing today’s hodge-podge

• Some mechanism for discovering places to sharethe content to

What am I sharing? A plain link, an OEmbed object, or what?

Where am I sharing it to? A social bookmarking site? A blog?

How close are we?

• Defining the content is coming along (Microformats, OEmbed, rel tags, etc.)

• Past standard exchange attempts have been, mostly, complicated (e.g. lots of drag and drop solutions)

• Content “targets” mostly all share a model (e.g. share.php?url=)

OExchange

http://www.oexchange.org/index_atk.php

A super simple protocol for sending content to a site. Where the target site controls the user experience, not an intermediate tool.

This includes:

• A common URL syntax for the share operation

• Simple agreement on a way to define types(“links” vs, other things)

• And basic discoverability via root XML, but nothing fancy (remember UDDI?)

How it works…

Our faithful User…

Is using a site (or other app), and wants to share some content.

That site, either itself or by using an intermediate tool, has a known set of OExchange endpoints for that type of content (“link”)

These endpoints are called Targets.

The targets have defined metadata, like:

•friendly name:my cool bookmarking site

• endpoint:http://www.mcbs.com/oexchange/share

That site, either itself or by using an intermediate tool, has a known set of OExchange endpoints for that type of content (“link”)

The site or tool forms a standard HTTP request to the target, like:

http://www.mcbs.com/oexchange/share?ctype=link

&url=http://www.example.com/thing-to-share

…and just sends the browser there.

The typing thing is simple.

A “ctype” parameter indicates the type of content, and it defaults to “link”.

So bookmarking tools don’t really have to change.

But there are also other defined types:• RSS feeds• OEmbed objects• raw tags (for fallback embed codes)• OpenSocial apps (gadget xml)• and lots more

The typing thing is simple.

A “ctype” parameter indicates the type of content, and it defaults to “link”.

That’s it.

It’s just like this works today.

Except everyone agrees to use the same URL scheme, and on a common set of types, and makes their UI flow with their own site.

So we can all move on with our day.

That’s it.

It’s just like this works today.

Oh wait, how do you find out about these targets?

Oh wait, how do you find out about these targets?

There’s also a simple discovery and registrything.

• you can add yourself to a standards-based Registry

• you can put an XML document on your root, so tools can find you

http://www.example.com/oexchange.xml

If you are a Target (which means you can accept OExchange shares):

(the XML looks something like this:)

<?xml version="1.0" encoding="utf-8" standalone="yes"?>

<oexchange>

<target id = "http://www.mytarget.com">

<homeUrl>http://www.mytarget.com</homeUrl>

<vendor>Friendly Industries</vendor>

<friendly>My Target</friendly>

<sharepoint>http://www.mytarget.com/services/oexchange</sharepoint>

<types>oembed, link</types>

<class>socialnet</class>

<thumb-url></thumb-url>

<allowed-sources>*</allowed-sources>

</target>

</oexchange>

Either way, the idea is that things that want to facilitate sharing can dynamically find and offer more sharing targets, and offer users better choices.

Hey, what about authentication?


The target manages it (hopefully using OpenID), since it dictates session lifetime and auth flow for its users already


The target manages it (hopefully using OpenID), since it dictates session lifetime and auth flow for its users already

Sharing should NOT include scraping or intermediate password input -- in-situ sharing buttons are cool, but ultimately not cool

…and the “open stack”?

…and the “open stack”?

• OpenID can be used by targets when receiving content

• OAuth could be built into a parallel flow in the exchange standard (though it removes some post-share control from the destination)

• Any content-oriented standards (microformats, defined meta tags) can be supported via specific types, or simply on top of the exchange

• The discovery document may become XRDS-Simple, if we can make it un-confusing to the long-tail

What happens now?

The network of sharing destinations can grow dramatically…


…so sharing tools can offer more personalized sharing prompts


…so sharing tools can offer more personalized sharing prompts.

…with more long-tail services.


…so sharing tools can offer more personalized sharing prompts.

…with more long-tail services.

…and more appropriate/targeted services (like language-specific).

And as a bonus, the middlemen are optional.

…so?

An increase in user sharing rate means increased link-back lift for publishers

A standardized sharing interface increases the network effect of the destination

Forces tools up the value stack; basic redirecting buttons are useless

OK, then.


http://groups.google.com/group/oexchange




Technology

About OExchange