Justicantus on Oasis

Let's make music streaming fairer by leveraging blockchain solutions!

Comment

Justicantus on Oasis

Justicantus is a music streaming service utilizing blockchain technologies that promote fair compensation to artists.

How the project worked pre-hackathon

Artists use Justicantus to publish their songs.

The song metadata including the title and IPFS hash of the audio file get pushed to the IPFS.

The writing to IPFS is being performed by a Google Cloud function that the frontend calls.

Listeners can subscribe to the platform and listen to the songs.

The song title and audio file are read straight from IPFS.

While subscribers listen to the artist's songs the played minutes are being stored in a database.

The played minutes are stored by a Google Cloud function.

Periodically, the stored played minutes are transferred from the database to the smart contract storage.

The periodical migrations from the database to the smart contract storage are being performed by a Google Cloud function (pub/sub).

Artists can claim their rewards for played minutes at any time.

Issues being solved during the hackathon

The above-described architecture has some flaws:

  • The audio metadata is available on IPFS and can be freely accessed
  • Users may lack incentives to use the platform
  • Users can potentially use third-party software to cheat
  • Artist and song registration could be expensive
  • The platform is fully transparent and exposes user data

Let's discuss these flaws!

The audio metadata is available on IPFS and can be freely accessed

Pinning song metadata to the IPFS allows anyone to pull them from the IPFS and re-distribute them on another platform.

Also, the only validations that were performed in terms of validating that the user is a subscriber were done on the frontend.

This means that anyone can, e.g. create a browser extension that removes those validations and allows users to skip paying the subscription fee.

Users may lack incentives to use the platform

The platform would serve those users who are fans of supporting artists via fair, transparent, and fast payouts for their work.

People who are not interested in the above-mentioned things could find it difficult to commit to using the platform.

Artist and song registration could be expensive

Artist and song registration in the pre-hackathon version uses Chainlink VRF for random number generation for the artist's unique ID in the system.

This means that the platform has to deposit LINK tokens into a VRF subscription, top it up once in a while and the artist registration is more expensive than it could be.

The platform is fully transparent and exposes user data

Since the platform did not use any privacy solutions all of the data is public.

Anyone can see which addresses have subscribed to the platform, for how long as well as how many played minutes each artist had at any time.

There might be reasons why users wouldn't want to disclose that they have been a subscriber of the platform.

Disclosing the played minutes of an artist might sway the user towards certain artists more than others, therefore preventing less popular artists from gaining traction.

What we did to improve the platform during the hackathon

Let's go through the improvements just like we did with the flaws!

Audio metadata encryption before pinning to IPFS

One of the ways that we can prevent others from reading the audio metadata straight from the IPFS is to encrypt it before it reaches the IPFS.

We used the following pattern to ensure metadata gets encrypted:

  • Generate an encryption key off-chain and store it during contract deployment (ChaCha20-Poly1305)
  • Add “encryptors” to the smart contract: addresses that are whitelisted to fetch the encryption key
  • The contract owner can set these encryptors (it is part of the deployment workflow)
  • Encrypt the song metadata in the Google Cloud function that is responsible for pinning data to IPFS

By encrypting the metadata we have ensured that no one is going to be able to decrypt the files unless they own the “encryptor” account and can fetch the encryption key.

Audio metadata decryption

Since we are encrypting data, we must also be able to decrypt it, right?

This is exactly what happens during the rendering of the artist's song list and audio playback.

We added a Google Cloud function that uses the encryptor account to fetch the encryption key and decrypt the requested audio metadata or audio file that was stored on IPFS.

This function also checks if the user who is requesting song metadata decryption is a subscriber or an artist, therefore preventing users from using third-party tools to cheat and use the platform without paying a subscription fee.

Incentivizing the people to use the platform

To incentivize people to use the platform we added these new features:

  • Exclusive songs by the artist
  • Participate in monthly song voting and receive a guaranteed prize

I will elaborate on these incentives.

Exclusive songs by the artist

Artists can mark a song as an exclusive and enter the price in the platform JUST tokens that it costs for someone to purchase it.

Anyone can purchase an exclusive song and listen to it, you don't have to be a subscriber.

When purchasing an exclusive song the song price will be subtracted from the user's JUST token balance.

Obtaining JUST tokens

Users can obtain JUST tokens either by buying them from the platform (the price has been set by the contract owner) or by participating in monthly song voting.

Users can withdraw their JUST tokens at any time for the same price as they bought them.

Voting for a monthly song

The contract owner can open a “voting period”.

The period can be of any length but the current idea is that it would be a monthly vote for the song of the month.

Users participate in the voting and once the voting period closes and the winner gets announced the users get their share of the rewards pool for voters, paid out in JUST tokens.

The amount of rewards per voting period is set by the contract owner.

Artist and song registration could be expensive

Pre-hackathon platform version uses Chainlink VRF random number generator for the unique IDs of the artists and songs.

This makes the platform architecture more complex and also makes artist and song registration more expensive.

Since Oasis Sapphire provides a precompile for random number generation we could remove the Chainlink VRF random number generator from our architecture and use the native one instead.

This solves both of the above-mentioned problems.

Platform data is now private and selectively exposed

We can now select the data we want to expose and the data we want to keep private.

This is because Oasis Sapphire uses a confidential EVM.

All of the transactions that are made to the platform smart contract from the frontend or via the hardhat project are encrypted.

The only transaction that is not encrypted is the deployment transaction.

What's next for Justicantus on Oasis

We will improve the user experience related to audio playback and overall usage of the platform. Another goal of us is to optimize the performance of the audio decryption component.

Built With

Share this project:

Updates