Vision / Mission

Our vision at Ujo is to empower music through a transparent and open ecosystem and our mission is to build resilient, sustainable and accessible infrastructure for artists, supporters, and developers. Through building towards the creation of a fair, efficient, and decentralized music ecosystem, we hope to enable opportunity and creativity to flourish.

Overview

To execute the vision and mission of Ujo, we are developing and designing the core technologies and protocols necessary to create decentralized music applications with a variety of services that further empower those applications and the users of them. We aim to provide the immediate benefits blockchain and decentralized technologies offer (self-sovereign identity, portability, provenance, payment channels, security), while balancing the use of infrastructure that provides world-class user experiences and legal compliance. We have defined four layers that compose the Ujo Platform stack.

Core Layer

The core layer consists of protocols developed as modular components that power the higher layers of the stack. These components will always be free, open source, and developed in collaboration with the greater decentralized technology community.

Because the music business can be legally complex with respect to territorial copyright law, transferable ownership, and many owners with different license types, we have had to design and implement new tools for a Web3 ecosystem to support licensing in a decentralized network. In addition to legally compliant design, we have thoughtfully added components that provide additional value at upper layers. These include a series of smart-contracts that include the following core functions: the Artist Registry, Licensing Handlers, Oracle for ETH to USD conversion, and Non-Fungible (NFT) Collectible Tokens. Along with these fundamentals at the ethereum level, we have also contributed to the development of COALA IP (a blockchain-ready, community-driven protocol for intellectual property licensing), and Constellate (a library and middleware for persisting linked data via IPLD to decentralized storage systems).

Artist Registry

The Registry is a publish/subscribe (pub/sub) event logger that allows individuals or applications to broadcast messages linking their ethereum address identity to metadata blobs stored off-chain via decentralized storage systems such as IPFS and Swarm using a Content-ID (Self-describing content-addressed identifiers for distributed systems). This allows event subscribers such as other service and application developers to retrieve the metadata and files associated with ethereum identities. Furthermore, we’ve designed this so that events broadcasted contain a schema.org and COALA IP compliant Content-Type so that all metadata is easily categorizable by listeners. An example event looks like this:

LogPublish(msg.sender, “0x9e22aa58bf2f5e60801b90fdd3b51b65d38ea20b”, “create”, “MusicGroup”, cid, prevBlock);

Licensing Handlers

The Licensing Handlers are smart-contracts responsible for handling licensing payments. Payments are input and the funds are disbursed to the appropriate beneficiaries towards a specific license referenced by it’s Content-ID. Similar to the Artist Registry these events are stored in the blockchain via event logs. During a payment, the handlers fetch the USD/ETH price from an Oracle (described in the next section), and notifies a variable amount of addresses of the action. An example of a notified beneficiary is issuing a collectible badge upon payment. The handlers enable proof-of-payments, granting the rights specified in the license to the licensor. An example event looks like this:

LogPayment(_cid, _oracle, ethUSD, msg.value, msg.sender, _buyer, _beneficiaries, _amounts);

Oracle

The Oracle contract is used to fetch the ETH to USD exchange rate. Currently this uses Oraclize, which forwards requests to get the rate from the Kraken exchange. The contract funds the Oraclize calls with ether deposited by an administrator (Ujo fulfills this role at the moment), and schedules the updates according to a set interval.

ERC-721 Badges

The Badge contracts contain an implementation of the ERC-721 spec along with a type of Non-Fungible Token (NFT) we’ve defined as a Badge. Badges are received for various actions users of the platform participate in including, but not limited to proof-of-purchases for music acquired through the platform. Other types of badges issued also include a variety of patronage tokens. We first realized the potential of cryptocollectibles and experimented with the concept in early July of 2017 with the release of the RAC album Ego in a custom Ujo store (which we wrote about in a post taglined: An Experiment in Tokenizing Social Capital). This was before massively popular dApps such as CryptoKitties, and CryptoPunks popularized the idea and garnered the widespread attention of the web3 community. We view this as one of the most exciting core components and will be continuously experimenting with the types of signals collectibles provide and the value it can bring to both creator’s and fans. Some of this value might come in the form of gamifying artist and fan relationships and encouraging participation in the network through unique incentivization schemes. Simon from our team has since written a follow up on the direction we are taking to expand on our early experiments which includes info on the idea of Continuous, Rare, Patronage Collectibles.

COALA IP

In addition to the smart-contract components of the Core layer, we’ve also done considerable amount of work contributing and building complementary tools we hope will benefit the greater decentralized ecosystem. One of these is COALA IP, which stands for The Coalition Of Automated Legal Applications — Intellectual Property Group (COALA IP). Members of the Ujo team joined the working group that formed when the need for a protocol for referencing licenses on the blockchain was realized. As stated on the COALA IP site: “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.” The initial implementation of the spec was built by BigchainDB. Following their lead and in close collaboration with their team, we built the JavaScript implementation of of the protocol last year. The need for a metadata standard that fits the requirements of decentralized licensing is not specific to only Ujo, and there has been a lot of continued interest in this project so we plan to continue iterating on this project in collaboration with the community.

Constellate

In tandem with the development of a protocol for metadata and IP, we also realized the need for simplicity for developers to interact with decentralized storage systems in a modular way. This sparked the idea for a library that would serve as a middleware to make uploading to networks such as IPFS and Swarm as simple as importing a library and instantiating a service object with the capabilities to put and get files and data to the desired backend by calling the associated methods for doing so. This library called Constellate abstracts most of the complexity of dealing with each network directly. This project is currently still a work in progress, but we plan to continue to iterate on the idea while open-sourcing the developments.