With the RAC release, we demonstrated the platform under the hood that is going to enable a future of scalable, machine-readable licensing.

It currently uses:

InterPlanetary Linked Data (IPLD) for crafting metadata about releases according to cross-industry standards. Ethereum for the settlement and disbursement of licensing payments. On-chain handlers are attached to releases. The InterPlanetary File System (IPFS) for storage of media and metadata.

With this, we can improve the process to license music for various uses and thus drive more earnings towards artists. Enabling license types that exist in the current industry is first on our roadmap (eg, non-commercial perpetual use, sync, streaming, etc). However, using Ethereum, we can enable a whole new set of licensing opportunities that weren’t possible before that can enable the artist to earn a living in new ways. For example, allowing a license to issue a badge to the buyer, enables the artist to give additional privileges to whomever holds these badges (like exclusive access).

In our release with Giraffage, we can demonstrate our technical progress towards our portal.

Too Real

Simplifying Handlers with Factories

A common pattern in Ethereum is to use on-chain contract factories. The reason for this is to deploy contracts through a trusted source: another smart contract.

Thus, if an app developer wants to protect their users from potentially malicious handler contracts, then they can check if it was created from a trusted factory. Whilst Ujo will be driving the creation of these handlers, the underlying platform is open so that other players can create their own handlers for various circumstances. Instead of having to trust every single handler, the trust is shifted to having to trust every factory instead.

This reduces the overhead for disbursement of funds, and allows app developers to eventually build out their applications with more ease of mind that funds will flow towards the artists.

Factory patterns differ, but this is the initial start for our portal as an example:

Connecting Badges

With this release, we are demo-ing a handler that directly connects to the issuance of the Too Real Album badge. With every album being bought, the fans get a collectible badge.

Previously, fans had to go claim their badges afterwards, but in this scenario, they are issued directly when the album is being bought. We are quite keen to experiment a lot with badges in the future.

It has the potential to be quite powerful, extending beyond collectibles, the possibilities are up to the artist’s imagination. We don’t just listen to music. Music also defines how we feel about ourselves, the world and the people around us.

Refining Constellate & JS-COALA IP

We’ve also been at work polishing Constellate and our Javascript implementation of COALA IP. Along with help from BigchainDB team, we’ve been refining our Javascript implementation that takes input upon registration and produces the relevant metadata.

Once this is received, we use Constellate to persist to our chosen storage systems (eg IFPS or BigchainDB).

These components are important as we move to a world where metadata is content-addressed: retrieving it not on where it is (a server), but what it is (the content itself). Linking to other content is defined as a hash-link. What’s great about this format is that the data can reference each other independent of where it is stored. For example, when I tell you to go read a new book, you can determine where to find it: Amazon, a library, a friend, etc. I will tell you to read “Sapiens”, not tell you to read the book that is in the 3rd row, in the 4th column at the local library.

This makes the standard a lot more future proof.

Indexers

In the medium-term we want to ultimately utilise a metadata tool that allows us to not only store the metadata, but to also persist it and make it easy to search and use. We are quite excited to move towards IPDB when it is live. Whilst we are storing metadata currently in IPFS, we have to build index/searching that are currently suited to our needs.

Conclusion

As we are building the Ujo Portal, we are also building out this platform in the back-end that will allow rightsholders to easily license their works. We will initially be focusing on the user-facing side in order to drive a catalogue of works, with Ujo both building the on-boarding & the creation of simple licensing systems.

When the product is mature and the back-end has gone through iterations, we will start surfacing this more so others can start building on top of this infrastructure. We are excited!