Why?
While building ValoBox and talking to publishers about our product, we’ve been asked a number of times about the potential for publishers to integrate ValoBox more closely into their existing retail channels. 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 micropurchases, but it got us thinking about how to solve a wider problem for publishers of paid content.
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 subscription websites and services, including some from publishers themselves. 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 several book purchases 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 them and what they can offer them. 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 the answer is to create a standard API between content services to share access to a user’s purchase information. Once established, this access permission API would provide a way for users to buy in one place, link their accounts and then have their purchases synced between all their platforms and devices.
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 reader and have your new book download automatically for viewing. When you purchase the book, the purchase information gets sent to all your platforms through the access permission API, each platform can choose what to do with the information. This could include making the book available there as well. It would mean no tedious downloading or copying required.
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 what they want to spend their money on. With an access permission API 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.
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 set of fundamental principles should guide the design decisions, I propose:
Open, free data format and API
Everyone should be able contribute additions and documentation without cost or competitive restrictions.
An API based on existing standards
Developers can use existing framework extensions and documentation being able to easily 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.
Proposed basis of a specification
Web developers have done the hard work for us and many tools exist for this kind of work. The core components we need are:
- a user authentication and access permission standard
- a common data format
- user authentication and access management.
The emergent standard for user authentication in APIs is Oauth2.0. The beauty of Oauth2.0 is its simplicity. It is designed so that any software that can make web (HTTP) requests (such as web browsers, servers or command line tools) can request information. Oauth comprises of two parts: the provider, which stores information, and the client, which accesses and sends information to the host.
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 to them and share certain information. Twitter and Facebook use Oauth to securely share user information with thousands of other applications such as Hootsuite.
As an example, say I run a publisher with the website publisher.com . I want to know what has been purchased, and by whom. I also want to be able to offer additional support for my products such as supplementary content and regular updates. This is how I can connect my system to a retailer (retailer.com ) and make this easy for customers:
- 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.
As part of a customer’s login or purchase process, they can choose to connect their publisher.com and retailer.com accounts. When they buy a book at retailer.com the purchase information will be sent to publisher.com as well. This means when the user logs into publisher.com their purchases will be shared, entitling them to the additional support I offer.
The beauty of this system is that:
- the user is in control – they choose who to share their information with
- only certain information is shared – access can be restricted to just purchase information keeping other details like login and password secret
- it is very scalable – once implemented connecting thousands of services together is easy
Other contending technologies for this task would be Shibboleth, OpenID and LDAP. I prefer Oauth due to the fact that it is simple and the Oauth client can be implemented without needing a complex server.
A common data transfer medium
disclaimer – this is in no way a formal proposal. It is just an outline of what might be possible and the basic technologies which could be used
The most elegant data transfer medium I know of is JSON. It is a simple data construct very commonly used when web browsers make requests for data. It is open and easy to manipulate in any programming language.
I propose a minimal data structure with the ISBN as the identifier for information about the purchase. The only data 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. These commonly used data formats would in practise be decided by a committee.
The alternative data format would be XML. Personally I prefer JSON as although not quite as powerful as XML it is 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.
Ultimately, I would like to see this as the beginning of a paid content ecosystem comprising of many content sources and services. I’d love to hear your thoughts on this proposal so please feel free to comment or get in touch with me.