We just launched the Ujo Public Alpha for testing: allowing musicians to register their works in a Creator’s Portal and license it to be sold in an online store.
What’s happening the in background?
The current stack comprises of using Ethereum, IPFS, an indexed back-end & the usage COALA IP for metadata standards.
Ethereum is being used for a pub-sub registry (publish/subscribe), an oracle, disbursement of payments & minting collectible badges when buying releases.
IPFS is used to store metadata & files through Infura.
Our back-end, written in Go, using Postgres, acts similar to a block explorer, where we index events: allowing us to serve, and search the content effectively.
We are serving the website currently from Surge & have our back-end hosted on Heroku & AWS.
Registering
When registering, we create metadata of the information that conforms to the COALA IP protocol. We have written & open-sourced a Javascript implementation: https://github.com/COALAIP/js-coalaip.
The content identifiers (CIDs) we submit to the registry & do not use on-chain storage at this stage. We simply use the registry as a way to submit event logs.
It looks as follows:
For example:
By issuer <address of issuer>: for subject <address of artist> log the creation (“create”) of a “MusicGroup” object that’s hashed to the CID <content ID of MusicGroup>.
Currently, artists themselves are the issuers. Like a block explorer anyone can listen to these events & build up their own database, which is what we are doing (more on this later).
Along with the metadata that’s published, any other media we currently store as-is on IPFS (hosted through Infura).
We store a copy of the metadata in our back-end database (Go + Postgres).
Buying A Release
When buying a release, a smart contract is used to log that a payment occurred according to certain standards: paid towards the appropriate release ID, the current exchange rate, who the beneficiaries were & the amounts disbursed towards them.
This information is gathered from the metadata we have stored.
As Ujo, we then validate whether this payment is sufficient or not & then disburse the files to the user. You might notice that there’s no on-chain validation whether the payment is enough or not. We’ll touch more upon this later.
Upon each payment, a notification is sent to our Badge contract that mints a badge with the details of the payment.
Signing-In
Like most modern web applications, Ujo uses JSON Web Tokens (JWT) for authentication, but contrary to the usual user-name and password login flow, Ujo uses Ethereum directly to allow users to authenticate themselves without any centralized datastore. Instead, users sign an arbitrary message using their private key that is securely handled using their Ethereum account via MetaMask. Through signing this message, it is possible to cryptographically verify the owner’s identity, which grants them access to create or modify resources on the Ujo platform.
In a consecutive post we will elaborate on the details of this and how we integrated Geth (go-ethereum) directly into the backend to make it as seamless as possible.
Trade-Offs & The Future
This architecture requires Ujo to exist at various places: indexing, payment validation & file disbursement. Ujo provides the centralized components that are necessary for it to work at this stage in time.
We launched one of the first working applications on Ethereum back in 2015 & have learned valuable lessons about building this infrastructure along the way. Some were hard lessons that resulted us in having to throw away code we’ve spent months working (more than once). We are constantly faced with the trade-offs of having to build a product used by users & building the platform that powers it. We have to build the car & the engine at the same time.
Balancing these trade-offs is hard. We can’t wait forever to build out the most perfectly decentralized architecture, only to have a product no-one uses. However, we have to have a product that’s compelling enough in its differentiation that people can use it today with the benefits afforded to us by current decentralized platforms.
For example: about 2 weeks before launch, during our team retreat, we realized that in order to ship sooner & to allow us more flexibility, we removed any reliance on on-chain storage. However, this meant we lose access to smart contract-based payment validations. Given the fact that we already disburse files based on on-chain activity, it wasn’t such a stretch to remove.
However, in doing that trade-off: a more minimal contract architecture at this stage allows us to have access to:
- More flexibility [more upgrade paths].
- Cheaper.
- More secure (less moving parts).
- Faster development cycles & product iterations. [Actually building something artists want].
- Less likely to pre-commit to poor architectural decisions [eg: decentralize too early].
This is at the cost of being less decentralized & requires us to build & maintain more infrastructure ourselves at this point in time.
That being said, we still get value from using Ethereum in that we get the ability to:
- have a decentralized endpoint to monitor the deployment of metadata.
- have payments done directly between fans & artists & having it recorded according to a certain set of criteria.
- collectible badges of patronage according the ERC721 standard, forever marking the proof of fandom.
Building up from here, we will over time move more & more towards building a totally decentralized infrastructure where Ujo (as infrastructure) is not required anymore. We will take the training wheels off as we continue our mission of empowering artists.
The requirements might change, but we eventually want to see:
Decentralized, Incentivized Storage
For now, Infura pins our metadata & files, but we are still hoping to see incentivized storage projects like Swarm & Filecoin fill this role.
There are other decentralized & incentivized storage systems available (like Storj & Sia), but the reason we are keen on Swarm & Filecoin specifically is that we want the information to be able to be accessed in the same networking substrate (libp2p or devp2p essentially). It will thus be easy to traverse directly from an Ethereum contract to retrieving a file through hash-linking without switching different networks.
Swarm will be native to Ethereum’s network, & there is work being done by the Mustekala team on piping in Ethereum data directly into IPFS using IPLD. It is close to MVP. So either way, one would not need to store files & metadata on disparate networks. As Juan Benet from IPFS describes it: it’s all just one giant merkle forest.
Decentralized Indexing:
We have to build up an index of all the metadata ourselves. Even if it were stored on-chain on Ethereum, we would still have to build some cheap, indexable search engine.
We had hopes on IPDB helping to fulfill that role but they’ve recently shelved the project.
For now though, most of the decentralized web relies on centralized indexing (see blockexplorers), so I don’t think it’s an immediate priority.
Decentralized Validation & Serving:
In the event that a payment is validated, the files would be made available & served to the buyer. Currently, Ujo acts as the sole operator. In this stack, the payments need to be validated, served & optionally encrypted.
There are various ways this can be achieved. For example: without the usage of cryptographic checks (such as hash challenges or other proofs), one can set up a registry of operators that prove they are acting in good faith. A token-curated registry comes to mind here. In that sense it might be good enough to allow Ujo to step aside and allow others to also serve files.
A project in this vain that is aiming to help achieve this is long-time collaborators: Ocean.
Conclusion:
With Ujo Alpha, we are using Ethereum, IPFS & our own back-end infrastructure to empower artists through our Creator’s Portal & Store. For now, our setup is fairly minimal so that we can iterate quickly on our product without compromising on the values that decentralized infrastructure provide.
Building decentralized applications is hard & over time we hope to take the technical training wheels off to provide a fully, decentralized music industry: one where artists remain in control & are empowered.
We are going to be open sourcing more of our components soon and hope you help build it with us.
Co-authored by Simon de la Rouviere & Alexander Attar.
