Project Update
At Kendraio, our goal is to develop, test and create a new way for web monetised content in the music industry. Our main goals are to:
1) allow streaming platforms to use web monetisation as a business model for fair, user-centric and transparent payments to their artists
2) to create a simplified end-to-end demonstration of a complete value chain from artist interface to DSP to universal player
3) to create a way to distribute and upload tracks in bulk that have the ability to be web monetised once ingested in the streaming environment.
4) To interface payment systems such as Uphold to create virtual cards (wallets) for specific royalty balances
Progress on objectives and key activities
In order to progress with our deliverables, we’ve built a web player within the Kendraio App as a workflow block. The web player has an OAuth2 verification and registration process that allows multiple DSPs (Digital Service Providers) to manage their tracks. At this point this only for Coil users, and only if there’s no Coil/ Web monetisation installed already. The web player enables the listener to find and play multiple tracks from artists streamed from multiple DSPs from within one interface. This required us to maintain role based permission for the various account types (i.e. listeners, artists, managers, DSPs). As of now, we’re using the Web Monetization API and we’re investigating the various implications. We’ve succeeded in switching between multiple payment pointers dynamically within one meta tag. Which, in and of it itself, is a great design pattern for the web monetisation community as a whole. One of the biggest limits before going into this project, seemed to be the inability to have multiple monetised creators (musicians in our case) within one webpage. There were only less than sub-optimal solutions for this, yet it seemed such a crucial point to the value proposition of web monetisation. We’ve managed to do so by dynamically adding and altering the payment pointer in a meta tag header when triggered by, for example, a play button. Additionally, we’ve created a functionality to start and stop payments that doesn’t require complicated event management in a program. The simple but powerful solution we found was to dynamically apply and remove the payment pointer when the music plays. This proved to be the most optimal way and seems to be working flawlessly when tested.
Regarding the distribution and ingestion feature, we have a working prototype that can ingest spreadsheets and convert large size files from DDEX format (the conventional format for music metadata in the industry) and we're still determining how best to add payment pointers at the distribution level. Furthermore, we’re researching ways to ingest (or potentially generate) payment pointers, so as to automate the link between tracks and payments. In this, we're partnering and collaborating with music streaming platform Resonate, which we're using as a proof of concept for real use cases.
Lastly, we’ve prototyped an integration to Uphold’s API using OAuth to allow Kendraio users to create cards (wallets), and list balances. This will allow users to be able to create Uphold virtual wallets in an automated way. Uphold allows users to deposit value into a specific card from an external source (ACH account, debit/credit card or wire transfer as well as Interledger Protocol deposits) or withdraw to an external source (ACH account or wire transfer). It will allows users to​​ retrieve the details about a specific account, which also allows recipients of funds to transfer funds to a single store of value, regardless of how the value was originally sent. By querying the API, Kendraio App returns the details associated with the card ID provided. You can see more of it in the video below!
Communications and marketing
We initially announced our participation with Grant for the Web in November on all of our social media, namely Facebook, Twitter, and LinkedIn. This project was also the main headline on our end-of-the-year newsletter that got sent out to more than 1,500 people and took centre stage in our 2020 Recap. It has opened up some opportunities and potential partnerships. We have also been working in our open Slack community. In our original planning, we were aiming to have user stories by now, but since we have pivoted away from having several musicians trial the project, to fewer DSP partners, like Resonate, these will take another shape in the coming months.
Our main marketing activity (and where all the budget we have allocated will be spent) is to create “bounties”, small development challenges we will be organising and distributing on development platforms and social media. These will generate interest in the project and will also help us innovate. We have realised that bounties are a very rewarding, but at the same time very difficult and cumbersome. They often take a lot of work and effort but might not lead to much value or community engagement
What’s next?
In the pipeline, we have real-life use cases with DSPs such as Resonate. Within this process, we want to integrate the bounties we mentioned in the marketing section and hope to reach many more collaborators. We’re also planning to keep a close relationship with the team at Uphold and do additional development with them in our app. We have consolidated more partnership with Envoke and are in still in discussion to partner and work with Raidar and OMI.
What community support would benefit your project?
We would also love to connect with more people within the Grant for the Web community who are working on music industry projects. We’d love to share experiences and see if we can collaborate or share insights. As we exit the grant, we would like to keep in touch and possibly help and continue development and partnerships with new cohorts who fit our goals and development interests.
Relevant links/resources
You can take a look at all our documentation in our public drive here: https://drive.google.com/drive/folders/1d2D_JMbM1EpM52Ju8nEYmXkU4rYgejL0
Top comments (0)