The fundamental concept in an Internet Bank of Content (IBOC) is that rather than giving a piece (as binary data) of sociable content to a web service, a participant in the social web would upload or locate that content in their Bank and provide a URI to the service, called a presentation service. The bank holds the content in trust for the individual.
Why is a bank desirable? What would the benefits be for a user?
- All content remains the user's.
- If a presentation service goes out of business, the user's risk or loss is more manageable.
- Any publication of content can be immediately rescinded by changing access policies on the URI (modulo whatever caching policies have been chosen).
- All URIs could have access policies or capabilities statements.
- Anything which can be captured by a MIME type can be stored in the bank.
- Individuals can host their own bank if they want: It’s just HTTP.
- Content can be published to multiple places by reference instead of copy. When changes are made, they need only happen in one place.
- The user has the option of maintaining several content accounts for multiple internet personas.
- Banks could differentiate themselves by providing different levels of service: different ways of managing access control, service level agreements, data sharding and redundancy.
- A suitably well featured bank could provide persistent and versioned storage for the user's entire data, ever.
What would the benefits be for a presentation service?
- They do not need to worry about storage quite as much.
- They can concentrate specifically on the UI and UX of their service, distinguishing themselves through innovations in that area, rather than commodity-level concerns such as quantity of storage.
How does this relate to the Federated Social Web?
"Social interactions [have] become the central point of our communication using the Web" (charter) but those interactions are, out of necessity, mediated through the distribution of content between services. Each piece of content has the potential to be, and often is, archived for future reference and distribution. The content becomes an artifact on the web. Our identities on the social web emerge from the collection of artifacts we each leave behind. Therefore the effective distribution and management of content is critical to the success of a social web, especially one that is federated.
As currently implemented with OStatus and its use of PubSubHubbub, social content is sometimes federated by distributing copies of content to multiple subscribing sites. While this is useful to avoid the so-called thundering herd problem the technique is a) not particularly forward thinking, b) presents a huge challenge to a user who wishes to revoke whatever it is they published: they either need to go round to each site and delete the respective data or some protocol must be developed which enables the same thing. Both of these rely on substantial cooperation from the hosting sites. Better just to revoke access to the one canonical URI of the content and be done with it.
Objection one is that the model implies a multi-step process to publish content: upload to the bank, then post the URI of the content to the one or more services that will present it. The counter is that such posting is exactly the kind of automatic handling computers can be trained to be good at.
Objection two is more complex: Why would a presentation service choose to allow their service to be dependent on content located elsewhere? This argument was discussed at some length on the Autonomo.us mailing list with no clear outcome. That people's content on the web is uploaded somewhere as bytes rather than as a URI is an accident of history, not a technical requirement. As such the pattern could be changed if sufficient benefits were the result.
The growth of the social web has caused a huge increase in concern about and awareness of the issues surrounding content ownership and distribution. The benefits of a URI-based model of distribution are now easier to explain as well as easier to implement.