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:

https://ipfs.infura.io:5001/api/v0/dag/get?arg=zdpuAwcW4HE8LS7oEJcUaCiTY4rnoxVh8Goi2JgxVZp9S9XGh/track/0/performingArtist/1/name

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

InterPlanetary File System

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.