Open-source music data has the potential to unblock several deep-rooted problems in the music industry, namely:
Enabling artists to own their audience and take them cross-platform
Allow fans to hop seamlessly between music apps with their identity backpacks
Enable builders to create new products on top of open data sets
But there’s a balance to be found. How to create a world where music data is open, while ensuring that everyone maintains control over how their data is used and monetized, while protecting their right to privacy?
Users repeatedly provide the same data to different parties across the web. Their handles; their addresses; their preferences; their activity. Applications repeatedly race to access the same data points, duplicating effort for each and every data point.
In a shared ecosystem—music—we don’t need to participate in wars of attrition. We can share data between applications without compromising privacy.
The data is there, and we’re working together to set it free.
Data federation provides a new paradigm currently used at scale when training ML models but scarcely used in consumer contexts. By standardizing the data that we transport between parties, the subjects of said data, and the authorization process, we unlock open rails for data.
Importantly, data shouldn't be public-by-default. Users should be compensated for access to their data, and facilitators of data should be compensated. There is no such thing as a free lunch, and a core tenet of the protocol is that it should include payment rails.
Protocols are hard. Proving data transfer, harder. We’re engaging with existing music organizations & new ones to help pilot such a mechanism, without the problems of over-engineering or going wide. By focusing on the space that we know and love—music—we can begin to deeply understand the problem, and apply solutions which have huge impact.
This will initially involve working with participants to open the data we have collected. We’ll standardise the data we have collected, and invite others to do the same. This is a crucial step. Without standardizing the data, we cannot solve the portability problems that the digital space writ-large currently must contend with.
While standardizing our schemas, we will develop data adaptors which will transform and aggregate user data, while preserving user privacy. We will track who has provided to whom, and ensure that those transport rails cannot be manipulated at the expense of data-facilitators or users.
As web3 natives we often want to build for ourselves and our friends. It’s an easy approach—a huge community is waiting, eagerly, for things to do. However, we believe that in the very early days, we can take a step beyond this and on-board people to data portability before they have to contend with key custody.
By providing sign-on tools which enable apps to request data from one another, we can also enable users without a web3 wallet to onboard, and they don’t need to track their public key to participate in spaces.
The approach, pioneered by others and extended by us, enables a user to generate a smart-account address. If the smart account doesn’t exist, we can assume that they haven’t deployed a contract and thus we don't need to check whether data exists about them elsewhere.
If the given user does however decide that portability is valuable to them, they may deploy their account, and begin to include an index of the applications which they use.
This enables any other app developer to first of all check whether a user has data at other sources, before then requesting said data. It increases performance, and mitigates requests for data that does not exist.
The smart account also paves the way for more complex key recovery & AKA mechanisms; it provides a gentle onboarding process to users for users who may not be interested in acting on-chain, but may be interested in the plethora of applications which can be built on open data rails for music.
Want to get involved? Sign the Oscillator manifesto and join our Telegram chat.
Carl Fairclough
