Ujo x RAC: Under the Hood - The Future of Licensing.
At Ujo, we are building a future where creators receive the commensurate value they are due. Together with RAC, we built a store to buy his latest release, EGO, that showcases how we are moving towards this future.
We envision a global, open, decentralized, machine-readable licensing system: owned by no-one in particular, but simultaneously owned by everyone. Its policies are set by the artists, upon which any app developers could build a service to incorporate the artist’s music in their applications.
We hope to see things like a young duo build an innovative radio service over a weekend without having to go knock on the doors of the record labels. We hope to see stems automatically uploaded and available for remixing from your favourite DAW (Digital Audio Workstation). We hope to see the first AI artist license their samples, and then be used in the latest vlog of a YouTube star that is yet to arrive. We hope to see decentralized bands reimplemented on this infrastructure.
Given this foundation, the possibilities are endless. It will all feed back to the artists, to the creatives.
Usage of media would simply be an API call away.
We’ve devised a system that improves the way current licensing is handled, but also opens up a large new scope for innovative and flexible licensing schemes. We saw glimpses of this when we launched the Tiny Human prototype with Imogen Heap in October 2015: a smart contract on Ethereum containing the rights that automatically sent payments to Imogen and her collaborators. We took the first baby steps.
On May 22nd, RAC announced that he wanted to release his album on the Ethereum network. We saw it as a good chance to demonstrate the potential of our architecture with him. In this collaboration, we are about 75% of the way towards finalising the different parts of this infrastructure. In this initial iteration, we had to manually craft the various components of the system, but also structured it in a modular and reusable way. In the future, with the introduction of our creator’s portal, we aim to automate this, and provide access to all artists.
The infrastructure consists of the following core components: Machine-readable Metadata, License Handlers and Decentralized Storage.
Metadata
One of the key issues for a machine-readable licensing system: is to have a standard that’s easily readable and digestible. This makes it easier for developers to license works for their applications.The Tiny Human Ethereum Smart Contract had rights information in it, but it was embedded in an Ethereum smart contract. Besides having to run a full Ethereum node to get access to the data, there was also no standard API to interface with it back then. We also have to consider a substantially more long-term future, where it could be possible that specific blockchain implementations can morph and change over time. A key design consideration was splitting of the data (rights owners, from the business logic: paying, rights transfers, etc). The data can then be referenced by any current or future blockchain.
With that, a group was formed in October 2015 to work such a standard. Ujo, BigchainDB, IPFS, Swarm, Jaak and many others collaborated over the course of the past year and half to establish such a standard. We didn’t reinvent the wheel and adapted existing standards to be more blockchain friendly, including hash linking that we’ve come to know and love: creating COALA IP.
COALA IP forms part of the CBOR IPLD specification that will allow us to in the future traverse this graph from metadata object right into Ethereum and other merkle data structures. The website includes access to the open source implementations.
“COALA IP’s goal is to establish open, free, and easy-to-use ways to record attribution information and other metadata about works, assign or license rights, mediate disputes, and authenticate claims by others. We believe there should be a global standard at the data level, without the need for centralized control.”
Along with content-addressing, this layer then becomes the starting point for licensing a work.
For the RAC release, here’s some of the metadata that was automatically generated using a system we developed called Constellate (that will become the foundational layer of our upcoming creator’s portal):
This metadata is currently stored on IPFS (thanks to Infura for pinning them).
For example, this is the release object:
https://ipfs.infura.io:5001/api/v0/dag/get?arg=zdpuAwcW4HE8LS7oEJcUaCiTY4rnoxVh8Goi2JgxVZp9S9XGh
With IPLD one can traverse this and even point to different details:
Within the release objects, you will notice there’s a license field that points to a smart contract. For this, we move to Ethereum, where each license will specify a handler.
License Handlers
A handler on Ethereum is a smart contract that contains the codified terms that have to be agreed to in order to transfer the right. For most licenses, there would be standard handlers that a program would know how to interact with (like a pay-to-download, or a streaming license handler). These handlers can be as flexible as one wants them to be, which could automatically include things like disbursing tokens when buying, attaching prediction markets to them, or anything a developer can dream up.This handler would be verified, so a programmer would know that it won’t run away with the money.
Along with the funds required, a specific license hash and handler is sent along with the payment to the Payment contract. The contract’s purpose is to log any and all payments occurring in this infrastructure (so application developers can listen for payments that occur). For now, it only takes Ether but in the future, you can pay with any token. With the payment, the handler checks if it is correct, and returns true or false. If the license hash and handler match, it’s a timestamped, settled agreement.
We built a specific handler, called RACHandler, that checks if the funds paid are correct and then automatically disburses the payments towards the label and RAC.
To pay, one issues the following command to the Payments contract using Truffle on Ethereum:
Payments.pay(‘zdpuAwcW4HE8LS7oEJcUaCiTY4rnoxVh8Goi2JgxVZp9S9XGh’, handler.address, 1, { from: myAddress, value: price })
This is saying: Pay the price required for the release directly towards the handler specified by the unique metadata identifier: ‘zdpuAwcW4HE8LS7oEJcUaCiTY4rnoxVh8Goi2JgxVZp9S9XGh’.
Decentralized Storage
The final part is storage: both for metadata and files. We want this to exist in a layer where we do not rely on specific institutions to host them.
Ethereum already replicates the required payment logic and thus is readily available.
For the rest of the storage however, the technologies available are primarily IPFS, Swarm, and IPDB. We are, however, looking at other decentralized storage solutions such as Sia & Storj that act more as personal, rather than public, storage.
Although we are of the belief that access to the files should be open in order to more easily facilitate licensing, this is something that’s ultimately up to the rights holders. Keeping some of this information and the audio files private and secure, whilst delivering an automated licensing system without a centralized party, are part of our infrastructure goals. Regardless of whether the files are private or not, most of the value of such an open licensing system will come from being able to generate new value and not about restricting access. For now, public is easier and we are starting with that.
For this release, the files are being served from an AWS S3 server that we maintain, but in the future, we will more readily move to systems such as IPFS. Restricted access will be optional at the discretion of the rights holders, using capabilities or other methods we are exploring. Swarm and IPFS’s Filecoin are building incentivization layers that will allow users to replicate this data across the globe, so there would be no reliance on specific institutions for this open license ecosystem to exist.
Finally, with regards to metadata storage, the constraints are a bit less as the amount of data is not as big as an audio file. Storage in Ethereum is on the more expensive side for the time being, with its usefulness coming primarily from being a logic layer, rather than a storage layer.
IPDB, a federated data store, will be a perfect host for helping replicate the metadata that the Ujo system creates in the short and medium term.
At the end of the day, it’s not required of us to be 100% future proof with storage layers due to the beauty of content-addressed systems. Protocols such as Multiformats allow us to aim towards future-proofing the storage layer today. This will enable the underlying networks to be swapped out if need be.
How do I find the right license?
The final component of this open licensing system is the ability to locate the correct license amidst the merkle-ized forest of metadata. Envisaging an automated payment system that’s decentralized and free of gatekeepers, so that application developers can instantly license the right music, requires that valid metadata is attributed and surfaced.
We’ve been working with other thought-leaders in the space along with music industry veterans to solve the last piece of the puzzle and will have more to show very soon!
Conclusion:
Although our architecture is not 100% decentralized and distributed yet, we are progressively working towards that goal. The technology and industry is maturing, and the parts are falling into place. With an automated, global, machine-readable, licensing ecosystem, we are excited to see more value flow to artists so that they can receive the value they are due.
The sun is rising, and the future looks bright. ;)
Thanks:
Getting to this point has been the work of many different players, all who are contributing to making this a reality. Thank you!
Thanks to RAC for helping us demonstrate this exciting future.
Thanks to all of the people at Counter Records and Ninja Tune for jumping onboard with this project and answering our many questions along the way.
