OExchange is a newly-introduced protocol stack that allows users to share URL-based content with any service on the web. It covers posting links to social networks as well as sending content to things like online translation and printing services.
The protocol — driven by the folks at Clearspring (where I work) with the support of a long list of online services — builds on several existing open web specifications. It is backed by an open development list, tools for developers, and lots of additional resources.
Lots of services accept URL-based content — social networks, news and bookmarking sites, communication tools, long-tail forums, translation utilities — and more appear every day. Why do blogs only allow users to share to the top few social networks? Why can’t users engage with more personal, relevant, dynamically-discovered options? Why are sharing tools and publishers still “integrating” with services individually?
As I’ve written before, users should be able to send content to any of an unbounded number of services. Sharing features should dynamically adapt to support the communities of interest users actually participate in and the tools they use, whatever platforms they are built on, and whether or not they are well-known. Services should be able to receive content from anywhere, in a common way. Basic interoperability benefits the web at large — services, users, and content providers — and we see a tremendous gap when it comes to simple URL exchange.
A common protocol means more content for services, easier integration for tools, more personalization for users, and more traffic back to publishers. OExchange defines the technical solution in three areas (take a look at the complete spec for all the gory details).
1. A way for services to receive content
Known as an “Offer” in OExchange terminology, this method maps onto the dominant model already deployed widely today. Specifically, for a service to be able to accept content via OExchange, it exposes an endpoint of the form:
This endpoint (which can be located at any path) accepts a set of standard arguments. Only one of these arguments, the url, is required. Anyone can send content to this service by sending the user’s browser to this endpoint. The receiving service controls any relevant authentication as well as other aspects of the user experience — the service is the one that defines what actually happens once the user sends their URL there.
A common method removes any and all service-specific integration requirements — all supporting services can accept content in the same way.
2. A way for services to make themselves discoverable
By building on top of the established XRD and host-meta specifications, OExchange makes it possible to integrate with services that you, as a content publisher or sharing tool, didn’t even know about at development time.
A service defines everything about itself in a structured and machine-readable document format (known as the OExchange Target XRD), and anyone that wants to integrate with it can easily locate this document using established means (such as host-meta references).
This makes it possible to determine that a service exists, and how to send content to it, dynamically as opposed through manual integration. The full discovery flow is outlined in the spec.
3. A decentralized, user-centric model for expressing preferred services
We are big believers in the promise of personal discovery. In OExchange, we recommend the use of WebFinger and, eventually, XRD Provisioning, to let a user publish a set of services they actually care about, in the form of service XRD URLs. The key idea here is that it should be possible to look up the set of link-accepting services (each expressed as machine-readable documents) appropriate for a given user. Tools can inspect this list and present the right options to the user at runtime.
Importantly, this list may include services the tool doesn’t actually know about — it can use the basic OExchange discovery mechanism to then figure out how to send content to this service. For example, imagine visiting a blog and being presented with not only the option to share content to the mainstream social networking service on which you have an account, but also the long-tail service no one but you and your 5 friends has heard of.
Do we need another protocol?
There is quite an open web capability stack available at this point, and OExchange leverages established protocols extensively. That said, there are a few things missing to accomplish certain domain-specific use-cases. For example, though there are any number of relatively domain-specific protocols that can be used to send content from one service to another, there are none which can offer a simple interoperability layer without introducing substantial requirements on the implementor. Its our belief that these requirements can counteract the benefit of the additional content to the service, and hamper adoption.
For anything that OExchange is newly-defining, it therefore keeps the recommendations as simple as possible, and actually takes pains to map onto predeployed models. Really, OExchange is as much a packaging of existing protocols into a specific use-case stack as it is a new protocol.
The strategy we’ve taken with the specification is to first codify an existing practice and be compatible with a wide range of existing deployed services, then to add a new service discovery capability on top of that, then to expand from that point into additional protocol actions and modes. In this vein, along with encouraging adoption and working to support the stack in the products we’re all building, we’re now beginning to focus in earnest on the additional capabilities. One often-cited example is an exchange mode that can take place without popping a new browser window/tab.
We’re pretty excited about a more interoperable web, thanks for the chance to outline it!