Building Ujo #1: From The Technical Underground To The Future
The history of Dubstep is quite interesting. While most have only become familiar with it when the genre broke out into the mainstream around 2009, it had been brewing in underground clubs for almost a decade. What looked like an overnight success was actually preceded by many years of relatively unseen experimentation.
From a technical perspective, we’re right in the thick of a nascent, underground movement. On the bill in underground “clubs” around the world are new & upcoming artists such as Ujo, dotBlockchain, Peertracks, Ascribe/BigchainDB, Resonate, Alexandria, Mediachain & Jaak, all playing around with the new “blockchain” sound. Our instruments are contemporary and have started to make some beautiful noise. We know the sound we want to keep striving for, but getting there means exploring it in our own ways.
The map of what the future of the “blockchain” sound will be is as uncertain as any emergent and budding genre. This is exciting for pioneers, as we can mould it the way we see fit. There are, however, various constraints that determine how we go about mixing & mastering our unique sound.
- Blockchain technology as a whole is still young. You have to consider the various ways in which it will mature over the next decade: scalability improvements, ubiquitous self-sovereign identity schemes, and decentralized storage & replication services are all still in development. Hammering in the foundations at this point in time might be premature.
- While we believe this sound is the future, the blockchain risks never fully breaking out from the “underground clubs”. We first need to focus on making sure this is something people will love and connect with before we buy new instruments and build out the ‘studio’ (i.e. scale our tech). A great artist can make compelling music with little resources.
With all the instruments available to us (Ethereum, Bitcoin, IPFS, IPDB, Swarm, etc), what have we chosen to play with? More importantly, how are we composing our sound?
Our Ideal Technical Stack:
- Ethereum & Smart Contracts are at the top. Ethereum’s flexibility in creating custom blockchain software for various purposes is unparalleled. It has gone through extensive battle-testing in the past year since it has gone live. The smart contract processing logic manages licensing, management of rights, and collective, economic, & self-organisation of artists. Given the interoperability amongst other applications in the Ethereum ecosystem, we can rapidly add new capabilities as they come live.
- Metadata (such as name, title, ISWC, release dates, explicit content, etc. ) is addressed using a common addressing scheme with translators (if required) connected to respective infrastructure. Re-usability of metadata amongst all the different layers is an important goal, as different players will use different architectures for the niche they are solving. For the future, we feel that IPLD would be the best to serve this, with COALA IP being the spec. In this case, the metadata would not be in the smart contracts themselves. The smart contracts would store what’s relevant for business & economic processing, and the rest is stored in this cheaper, faster metadata layer. Replicating this information will be useful, thus services such as Mediachain, Filecoin (for IPFS), Swarm, & IPDB are needed. Different consensus layers (self-governance) apply what they believe to be the correct metadata for their purposes. Ideally, an indexing/searching system across this layer would help (such as with IPDB).
- At the storage layer, files themselves need to be treated similarly. Services such as IPFS & Swarm can provide this backbone. Ideally this layer is properly incentivized to replicate the files for redundancy.
The end result would be a world where artists will have a persistent identity, can freely license their rights to their own policies, & collectively self-organise for economic gain without any intermediaries.
Our Current Technical Stack:
Since many of the previously mentioned stacks haven’t matured yet, and we are focused on proving that our product could be useful, we have put various training wheels on:
- For the time being, we are using Ethereum to host the economic logic (contracts) and to replicate our metadata. Ethereum can also be used for storage. While it is more expensive to store & maintain, this results in having less moving parts to maintain for now. The smart contracts primarily consist of registries, schema verifiers, and factories at this point in time. Each work & artist will have unique persistent identifiers. We use schema.org to build out our fields in our metadata. We will eventually map a translator of the metadata contained in here to fit with the COALA IP spec so that if other services want to reference to the metadata in our platform, they can do so.
- We use INFURA to host the image & audio files in IPFS, as well as to interact with Ethereum. Since we don’t currently have an incentivization layer, we need to host (and pay for) storage ourselves. These files can be replicated by users themselves if they want even more redundancy that it will remain available.
- Additionally, we have a proprietary back-end that monitors the rights that are registered & licensed, which is stored in Azure so that we can index/search it more easily. This is built with Nethereum. In the future, we hope to move the indexing/searching to an open layer as well, but we will most likely maintain a back-end that has additional analytics/indexing on it (much like how block explorers currently work in cryptocurrencies).
- For our front-end, we use Truffle to handle contract management & testing, use Redux/React for managing app state, and Webpack for build management.
- The Ujo site primarily works by interacting with an injected web3: in other words, it will work out of the box with Metamask & Mist. uPort support will be added as soon as possible. Mobile interfaces are currently a bit more tricky at the moment and we hope services such as Status and uPort will allow easier use of Ujo through those interfaces.
In time, we will detail more of these components with their own technical blog posts.
Upgrading the Stack & Going Forward
We are working with a technology that is asking questions that have never been asked before. Blockchains give us the ability to create micro economies on a global scale, constructing hypotheses that continuously need to be tested. As the industry continues to evolve with time, we are putting aside the deeper, harder technical problems until we feel we are providing value currently to our users. This means that although we have some unsolved problems out there, we are adding in the capability to upgrade the platform with new functionalities. At first, we will have relatively full control over the functionality platform — where users will still control and be able to delete their own data. We might even cede the control to upgrade the functionality to the community in the future. Eventually, all training wheels will be taken off so that ‘no one’ is control of the core architecture anymore. For rightsholders, we’ll uphold full ownership of rights. You will always own everything.
We expect several refactors as we test this out with our artists. Some of these refactors could include scrapping the current state and starting anew. We promise that what we build together you will never lose, no matter what.
Decentralized app development is a different beast to normal web app development
Given this approach, we can rapidly test the platform: both for technical & product reasons. By having the capability to upgrade functionality, we can experiment with adding in products like WeiFund, Boardroom or uPort seamlessly: adding in native crowdfunding support, collective management of artists and other artist collectives, and a persistent identity.
We believe that adopting a path of full decentralization too early means that we are pushing a solution on users that could be sub-optimal for the future. We could slowly but surely build what we regard to be the best fully decentralized infrastructure, but that leaves us without the ability to test product assumptions early on. More importantly, it won’t allow us the capability to empower artists right now!
We still aim to start onboarding artists by Q1 2017. This will give us the opportunity to keep experimenting with this new blockchain sound at a more rapid pace. You can never be too sure who will become the one hit wonders and who are the classic power houses. And if we don’t start experimenting, we can’t play with this new sound. I’m fairly certain this sound will eventually break out into the mainstream. While we wait for the technologies we want to use to develop into full maturity, we have our ideal technical stack as our roadmap to help us get there.
Send us your thoughts!
This article was written by Simon de la Rouviere, who leads technical design on the Ujo team. If you’d like to discuss some of the ideas in this blog post make sure to follow Simon on Medium, feel free to reach out on Twitter or Simon@ujomusic.com.
