Sharing, loosely defined, is one of the key use-cases for web-wide interoperability. It is also central to the discussion of a “more open” alternative to the dominance of a few key players. A truly open content sharing model is more than a domain that starts with “open”, more than deciding whether you are a Twitter person or a Facebook person, and more than an open-source version of a popular commercial service.
Users should be able to share any content to any one of an unbounded number of services, in a completely personalized way. 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, whether or not they exist at design time. Services should be able to receive content from anywhere, in a common way.
AddThis is a business built on sharing, but we believe that basic service interoperability benefits the web at large — services, users, and content providers. I’ll explain our view of this sharing model and, more importantly, how to practically implement it today with a suite of open specifications, including the recently-proposed OExchange.
Trends that Matter
Key trends emerge from an analysis of real data about how people share content online, at scale.
- There is tremendous demand in the long tail, both in the US and internationally. Facebook and Twitter consume a lot of online sharing. But so do other big international social networks like StudiVZ and Hyves, so do long-tail services like Amen Me, and so do more “traditional” services like email and (gasp) printing services. AddThis has a backlog of almost 1000 services this month. The desire that users have to share their content online far outstrips the integration capability of any sharing tool, nevermind that of a content publisher.
- Traffic in matters more than traffic out, and the data is surprising. The number of links sent into a social network isn’t what matters; its how those links multiply into clickbacks to the publisher. Sites like StumbleUpon represent a much more efficient clickback loop than Facebook, for example. We all experience cruft in our most high-traffic social feeds. We need tools that are able to optimize in more sophisticated ways, that take this phenomenon into account. Content distribution is not about flooding the stream.
- Sharing, Posting, and Liking aren’t the only things users do with web content. They translate it with online translation services, they send it to formatting and printing services, they add it to their personal organization tools, they save it for later. The set of verbs involved is much greater than “sharing”, “posting”, and “liking” — its in fact almost infinite, especially once internationalized. Protocols and tools must support this.
- There is no such thing as an ideal UI. The buttons and menus, the highly-designed icon rows, the complete drag and drop systems, you’ve seen all of them. The effectiveness of a treatment at fostering virality is much more a function of its integration into the page or browser than to any particular treatment in absolute terms. The easier it is for a user to find and use, the more it will be used. APIs and open protocols are the only way to satisfy the huge variety of need here.
- Personalization is key. Publishers should think of sharing tools like they think of ad tags — they present the right prompt to the right user at the right time, for the purposes of increasing clickthrough to recirculating services that generate value back to the publisher through incoming traffic. Scaling this past the top one or two most obvious options requires an embrace of the users actual communities of interest. It doesn’t matter if a particular service has little traffic; if you can show the users of that service that option, and no one else, you can increase the clickthrough dramatically.
A Modest Proposal
We’ve been openly-developing a specification called OExchange which we believe enhances existing open web specifications and best practices to form the basis of the open model we just described. OExchange includes:
- A descriptive model for content exchange, via a standard endpoint and user flow, that maps exactly to the already dominant pattern deployed on the web today
- A new capability for service discovery, allowing services to publish their endpoints, and tools to locate those endpoints
- A proposed mechanism for user-centric, decentralized personalization of sharing options
It also includes a path toward future extension. Let’s discuss the solution in each area in more detail:
Content exchange: How does one site/tool exchange URL-based content with another? What does that interaction look like?
OExchange defines a simple verb, Offer, to facilitate the sending of URL-based content to a web service. This transaction takes place via HTTP browser-driven GETs, in a pane of its own. The specification is intentionally set up such that almost every existing live content-ingesting service is compatible with it. For example, you can post to Google Buzz:
Offer also defines additional mechanisms to indicate a preferred additional content type (flash objects, images), but does so while avoiding complex type negotiation. The core principle is that there is ALWAYS a primary URL being exchanged, a URL which can also self-describe in any manner it wishes. You can read more about the Offer semantics in the specification.
Service Discovery: How does one service describe its exchange endpoint? How do you locate appropriate services?
OExchange prescribes the use of an Extensible Resource Descriptor (XRD) document, with a set of defined Property and Link elements, to describe services. Hosts can then include /.well-known/host-meta documents and in-page meta tags to refer to it. Any service that accepts URL-based content can describe its endpoint and other details necessary to send it content, and any host or page can enumerate and point to available services. This allows tools to support cases like “send this content to myfavoriteservice.com”, as well as locating available services as a user browses the web. The specification generally removes the need for any a priori integration as a requirement for online content sharing. Read more about it in the specification.
Personalization: How does a tool or site present options appropriate for a specific user?
Sharing tools have long attacked this problem (often called the “NASCAR problem”) using things like the user’s preferred language and their sharing history. There is a recently-proposed shared-domain solution, XAuth, that helps in some cases. What we aim for, though, is a mechanism to allow a user to optionally publish their personal service preferences publicly, for all tools to share, across machines, whether or not the user is actively logged-in, with a low-touch retrieval method. OExchange proposes that we build on emerging personal discovery ideas to accomplish this, publishing preferred services within users’ personal XRDs (as described in the spec). Though the relevant standards work on XRD Provisioning and WebFinger is still underway, we believe this decentralized model to be practically implementable with very little effort, and to provide the right optional extension point for users that wish to expose information to allow their tools to perform better. A large-scale provider like Google, who pushed support for WebFinger by enabling it for all GMail accounts with a Google Profile, can allow you to programmatically edit your personal XRD, then services will easily be able to add themselves, with your permission, such that sharing tools can determine your favorite services even before you share to any of them. This can also form the basis for inclusion of personalized sharing into a browser (or even a “social agent“).
Future Directions for OExchange
The three areas of additional current active work and likely next steps include:
- extension to other exchange models that do not involve a browser flow (so-called “headless” operation, via things like atom publishing)
- finalization of the suite of personal discovery mechanisms
- user-to-user, service-negotiated sharing (via the addition of service-specific “to” semantics on the exchange verbs)
If we can embrace the current paradigm, codify it, and add discoverability, then we’ll have a dynamic content exchange system in place. With this deployed model, attacking these next-level features becomes entirely practical.
So What Now?
Learn more at http://www.oexchange.org. Take a look at the demo, or jump right into the Quick Start Guide. We’ll be pushing this aggressively in general as well as in our products, and encourage you to get involved as well. We’ve put forth OExchange in a completely open way (open source, open discussion, open goals), as a true protocol, with practical interoperability with hundreds of existing services and well-defined and feasible extension steps. In the end, its in all of our interests to keep the web recirculating.