Introducing Oscillator:
the protocol for music & more
Data deserves to be unlocked
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
Preserve privacy; action data; open rails
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 process to reveal privacy, we unlock open rails for data.
However, we do not believe it’s feasible for this data to be open-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.
From 0 to 1
Building a complex system with others
Protocols are hard. Proving data transfer, harder. We’re engaging with existing music organisations & 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 those who participate to open the data points we have collected. We’ll standardise the data we have collected, and invite others to do the same. This is a crucial step—without standardising 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 privace. 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.
The identity problem
Web3 users are not the only people who deserve portability.
Web3 natives 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 haven’t deployed a contract and thus we cannot 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 mitigated 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.
Join us now
Build on the new stack for music.