While building ValoBox we’ve been working with a number of publishers. We’ve been asked a number of times about the potential for publishers to integrate ValoBox more closely into their existing direct retail channels such as a ‘Read now’ button on their eCommerce site. This has been an intriguing element to look into, particularly as it goes to the heart of what we are really interested in: making the content within books more accessible. Our platform does it through enabling browser-based reading and micro-purchases, but it got us thinking of ways to solve the wider problem of paid content fragmentation. The problem – a fragmented content ecosystem The crux of the matter is that the paid content ecosystem is getting very fragmented. There are traditional ebook retail platforms such as Amazon, Kobo and Apple, enhanced content platforms such as the Appstore and Google Play, and then a variety of smaller retail and subscription websites such as Penguin, O’Reilly and Safari. All these platforms distribute different versions of the same content i.e. a book in the form of an EPUB, PDF, app, or online stream. Such fragmentation is inevitable given the breadth of the content industry, but it is a pain for consumers and publishers alike. As a consumer buying a book I have a lot of decisions to make – where to buy it, what version I want and which platform I want to commit to. After purchasing a number of books I can end up searching through a number of different apps and websites to find the book I bought a few months ago. For publishers it isn’t much easier. To reach a wide audience they have to push books into all kinds of channels. Very rarely do they get a direct channel to customers. This limits what they know about consumers and what they can offer. It also means they have to manage a number of relationships with content platforms, which all operate in different ways. I believe something is missing, something which gives customers the ability to share information about content they have already purchased with other platforms, or accounts. This would enable customers to benefit from a choice of formats, platforms and enhanced content, without having to repeatedly pay for the same core content. The proposed solution – an API to share a user’s purchase information I think a strong case can be made to create an API to enable content services to share a user’s purchase information. Let’s call it the Open Library Standard (OLS). It would enable a user to connect their accounts on different platforms so that their purchase information could be synchronised. This would provide a lot of benefits, not only for the user but also for publishers and content services. Here are some initial ideas: Buy once, sync everywhere Imagine being able to buy a book from your favourite retailer and then open your favourite ebook reader, made by a different company, and have your new book download automatically for viewing. In this instance, when you purchase the book, the purchase information gets sent to all your platforms using the OLS. Each platform can choose what it does with the information such as making the book available to read there too. It would mean no tedious side-loading or manual library management. Access exclusive supporting content and updates As a publisher you may often want to make supporting or updated content available to those who have bought a specific book. An access permission API would mean you could incentivise those customers to connect their account with you by granting them access to this extra material. You would then have a direct relationship with the customer and the customer would get even better value from their purchase. This would work for both digital book or paper book purchases. Upgrade and enhance your content An enhanced edition or audio-book may be more expensive than a standard copy. At the moment the user must decide upfront which they would rather spend their money on. Using the API to transmit your purchase information, the enhanced edition provider could offer an upgrade to the standard edition for a reduced price. The same principle could apply to sites that may offer better social tools or services for particular books – perhaps an academic site offers additional citations or a way to share comments with particular groups of users. Now I can hear people saying ‘but large-south-american-river will never join that’ which is true, but this would provide a framework which goes some way to removing the negative aspects of choosing a different retailer. A consumer could buy with confidence knowing their purchases are portable to other platforms. What would the access permission API look like? A cross platform API needs to be easy to implement and maintain, but flexible enough to be future-proof. I believe a good start would be to establish a set of principles to guide the design decisions, I would propose: Open, free data format and API Everyone should be able to contribute additions and documentation without cost or competitive restrictions. An API based on existing standards Developers can use existing framework extensions and documentation that’s easy to customise for their requirements. A minimal but extensible API The API should be the minimum viable implementation to share the relevant information. This will make it easy to implement and maintain. It should also be flexible and extensible so if a provider wishes to offer additional information there is a sensible structure and place for it. Decentralized system I believe that the system should be decentralized. This means each platform connects to one another independently based on a data standard. This removes the need for gatekeepers who might stifle innovation. It also creates an open system in which anyone in the content community can choose how to link their systems together. Of course a distributed system affords for hubs to appear as well. At this point I’ve hopefully explained the goal of the OLS and how it might work. From here on the post gets a bit more technical which might scare/bore/frustrate a few folks so advance at your own risk. Concept basis of a specification Disclaimer – this is in no way a formal proposal. It is an outline of what might be possible and the basic technologies which could be used. Web developers have done the hard work for us and many tools already exist which could fulfil the requirements of this kind of work. The core components we need are: a user authentication standard a common data format The emergent standard for user authentication in APIs is Oauth 2.0. The beauty of Oauth 2.0 is its simplicity. It is designed to be easy so that any device which can make HTTP (web) requests can use it. These systems crucially include web browsers, mobile apps, servers and command line tools. Oauth comprises of two parts: the provider, which stores information, and the client, which accesses and sends information to the provider. If a publisher wishes to offer perks to customers in return for them signing up for an account they can create an Oauth provider. As a provider they can enable customers to connect and share information. Twitter and Facebook use Oauth to securely share user information with thousands of other applications such as Hootsuite and we use it at ValoBox to enable quick login via other services. As an example, say I run a publisher website publisher.com. I want to be able to offer additional support such as supplementary content and updates for purchases my customers have made on other platforms. This is how I can connect my system to a retailer (retailer.com) and make it easy for customers to access their purchases from retailer.com on publisher.com and vice versa. Step one is setting up the system and connection, a one time process: I implement the Oauth provider on publisher.com retailer.com implements the Oauth client on their platform I send retailer.com an access token so our systems can talk and their users can securely connect our services together. Now, the customers will see an OLS link and can opt to connect their retailer.com account to publisher.com. The process is the same as the ‘sign in with Facebook/Twitter’ links you use around the web. Once connected the information about books bought at retailer.com will be sent to publisher.com. Publisher.com then knows what has been bought and so can offer the customer the additional material and product updates. Any number of customers can then connect their accounts with no extra work by either the retailer or publisher. The beauty of this system is that: the user is in control – they choose who to share their information with, personal information does not need to be shared – the two sites don’t need to know the username or password of the other site but can share information such as the purchases securely, it is very scalable – once implemented it is possible to connect to thousands of services by generating a new access token for each service. Other contending technologies for this task would be Shibboleth, OpenID and LDAP. I prefer Oauth 2.0 because it is simple – the Oauth 2.0 client can be implemented without needing a complex server. A common data transfer medium The most elegant data transfer medium I know of is JavaScript Object Notation (JSON). It is a simple data construct very commonly used when web browsers make requests for data. It is lightweight and easy to manipulate in any programming language. I propose a minimal data structure with a unique key as the identifier for purchase details. In the case of books using something like an ISBN would make sense. The only detail that must be given in this information is the ‘state’ (purchase state). For example: { “ISBN1”: { “state”: “purchased” }, “ISBN2”: { “state”: “purchased” } } The great thing about this format is that it can be easily extended. For example, if one service wanted to send a bit more information. Such as: { “ISBN1”: { “state”: “purchased”, “date”: “2012-06-13”, “format”: “epub” } } The extra ‘date’ and ‘format’ can be used by some systems to determine purchase date and file format and ignored by other systems which can’t use that information. DRM information could also go into these details. These commonly used data formats would in practise be decided by a committee. If a particular service wishes to supply more information than the details defined in the standard they should add a vendor prefix so that other platforms can easily ignore it such as: { “ISBN1”: { “state”: “purchased”, “date”: “2012-06-13”, “format”: “epub”, "valobox": { "fraction-purchased": 0.6, "url": "reader.valobox.com/streams/510 } } } The alternative data format would be XML. Personally I prefer JSON even though it’s not quite as powerful it’s lightweight and can be easily understood by web browsers. The future The API would be the first building block for a community of content providers, distributors, services and users. It would give a user greater choice when purchasing and easier management of their content. Publishers and reading services would be able to offer specific benefits to the content rather than reinventing the same features available elsewhere. I would love to see standard industry API’s available to enable the community to connect our favourite eReading apps together giving us the choice to purchase, read and share using our favourite platforms. Ultimately, I would like to see this as the beginning of a paid content ecosystem comprised of many content sources and services. There are also lots of applications for this outside of books; perhaps you purchase a music track or a mobile app and want it to work on your other platforms without buying it again. At ValoBox we’ll be building upon this idea as we work with our partners and I aim to put a website together to act as a central point for information about the standard. I’d love to hear what the TOC community thinks of the proposal so please feel free to comment or get in touch with me.