The Hyper-Music App
Three years ago as founder of co-operating.systems I initiated a proposal that brought together a consortium of top European partners¹ to get EU funds to build a Sovereign decentralised platform based on Tim Berners-Lee’s SoLiD, which he is now pursuing with private funds as part of his Inrupt startup.
Imogen Heap’s who has been working relentlessly to give control of music back to those that make it, inspired this use case. Her MyCelia project has been involved with Blockchain and Linked Data technology to invent ways to help Musicians, bands and the whole musical economy surrounding them... The proposal sketched here takes this a whole step further by including:
- artists such as Imogen Heap who controls most of her music production;
- individual citizens who would like to publish birthday songs for the consumption of their family alone;
- large and small Indie producers;
- and even some of the largest publishing houses that could do with a more open market
The argument outlined here should be simple enough to understand yet also illustrate what is at stake, and outline the direction of an answer.
Why not just publish to the web?
Let us start by asking a simple question: why don’t musicians simply publish their music on their own web site as would have been possible since 1995? After all, it is pretty much within anyone’s ability set up a web server and get an attractive domain name pointing to it. Cloud services are available to make this a reasonably easy proposition. Why could a musician who did that not be then in control of his music distribution world wide? What is missing?
It does not take long to see two problems with this: one economic and the other relating to the user experience. Both of these problems can easily be understood by comparing this Web 1.0 answer, to what could be called the Web 2.0 services provided by iTunes or a streaming music service like Deezer.
Let us start with user experience problem, as that is something we can all understand easily. Suppose that every musician would publish his music on his own web site and that he could be compensated in one way or another for it. It is clearly very unlikely that all musicians would come to agree on a set of user interface conventions for how to build a web site. Each musician wants quite rightly to personalise his web site to correspond to the music he is publishing. We can easily understand why the look and feel of a classical musician’s web site would differ dramatically from that of a Goth musician or that of an artist producing electro music or from Imogen Heap’s web site. Music lovers on the other hand like many different types of music by many different artists. At the extreme: an eclectic musical audience — one who’s french radio station FIP.fr caters to — would want to listen to music by any one of these artists in succession. If such an eclectic person, call her Elena, had to go to each web site, she would need to:
- go the the band’s home page, either by clicking on a list, or by clicking a search engine result web page, or by typing in the URL directly
- if in luck she will arrive on a page published in the language she understands. For an English or Chinese audience that prefers local music that may seem self evident. But one cannot expect each musician to translate his web page in each of the 6500 languages spoken in the world, and yet there is no reason why music cannot have a global audience.
- If the previous hurdles are overcome she would then need to understand the set of conventions the artist web team used to publish the music. Which tab should one click to get to the albums? Which one for the musicians touring calendar? Where is the bio? etc…
This then brings us to the final problem which is how could one pay the musician for the music listened to? Where is the payment button? Does one need to enter one’s credit card details? Where? This would be like going to amazon.com and finding that each product had it’s own payment system method and layout. Given that the horrible security property of credit cards — once given out it can easily be used again for a different transaction — the trust issue looms large. It is clearly much easier to trust one of the few globally known brand such as Apple, Deezer or Amazon, than to trust one of millions of artists some of which produce under the worrying name of “Devil” or “The Grateful Dead”.
The Hyper-Music Navigator App
It turns out that there is a way to solve the interface problem: we can both allow the artists to have their personalised site and give the music lover a consistent interface on all music published by bands world wide. How so?
The idea is simply to extend the concept of the World Wide Web Navigator — the first globally successful hyper-text application — to a music Navigator with write capability. Each musician could publish his individual songs or albums on his web site with such an application to a SoLiD server — an extended HTTP server with read/write ability and access control. In addition to publishing the music, any images and texts, the app would also publish the relevant machine readable description of the music and of all the people and institutions that went into the production of the music — from band members, to recording studios, to marketing agencies, … —, the copyrights (or indeed creative commons based copylefts), and information about payment mechanisms, etc… We can already see that since a piece of music is a social creation, it will need to link to data published on other web sites. This is what hyper-data was developed for at the W3C under the Semantic Web project. The machine readable descriptions can use ontologies — a form of declarative Object Oriented language designed for the web — now widely taught around universities throughout the world, and used since by the life sciences, nasa, and many other linked data projects. Of course neither musician nor user need understand this logical formalism: the only people that need to know are members of the app developer team. Having published the new song, the app could ping any number of search engines about the availability of the new musical piece.
From the music lover’s perspective all she would need to do is open her favorite Hyper-Music Navigator App, and given either a QR code or hyper-link, reach a now unified view of the musician’s work. Alternatively the music lover could just search in the app with a few keywords and be shown a friendly view of the results returned by the specialised music search engine mentioned earlier. People could also share music lists on the internet that point directly to each band’s work. In each case the music could be served directly by the band’s SoLiD web server.
Furthermore since the protocols and formats are all open standards, different apps could cater to different communities. My father who after a career teaching political science is now singing Opera, may prefer a music app that showed the unrolling partition of the music he is listening to. A Musicology scholar may wish to annotate the music and save those annotations to his own SoLiD web server. A blind person may prefer yet another interface... And of course just as there are different browsers for laptops, cell pones and smart watches, so we can predict that we will find the same diversity for our hyper-apps.
(For a deeper overview of the architecture summarized above see “Epistemology in the Cloud” article I published earlier this year)
Hyper-App payment and security
This leaves the payment mechanism. One way much discussed by Imogen Heap’s group would be to use the blockchain for payments. All that would be needed would be for a link from the description to a blockchain payment system and the minimum payment required. But there is no reason banks could not also be involved by giving each of their clients a WebID and linking that to a LDP Container allowing the user to make payments to a different account by just posting a graph containing the payment request. Both systems would be furthered by the competition, and have their advantages.
We are the left with a problem of how a user downloading and paying for some music can be be sure to be paying the band that made the music and not some other entity that had illegally put the music online too. To make sure that can happen hyper-apps as well as browsers need to be able to identify the legal entity requesting payment as well as the payment service and locate them in the legal space of nation states, make this information available to the browser in an intuitive way. As I have argued elsewhere this requires an institutional web of trust bound into a web of nations in order to enrich the security of https. For more on that see the two posts:
The above sketch of a hyper-music navigator would then allow musicians to be in control of their music, marketing and sales, thus enriching the music ecosystem, and give the user the freedom to choose among a number of different navigators to match his particular preferences. I have only outlined a few of the advantages here. As always opening a market to competition will have many additional undreamt of benefits.
[1] The partners consisted of the Oxford University and University of Southampton’s Sociam teams, The Digital Catapult, INRIA, Bryan Ford’s Decentralised and Distributed Systems group at The Ecole Polytechnique de Lauseanne (EPFL), The University of Luxembourg, Open Health Care UK, and a number of smaller companies and startups of which Imogen Heap’s MyCelia, Eccenca GMBH (a startup linked to the German Frauenhofer Institute) and Mnemotix (Linked to INRIA).
We came in second and so failed to get the 5 million euros funding. In the mean time Tim has looked and found private funding for his widely talked of and recently unveiled startup Inrupt to develop the project.
