In March, I have been spending a whole month in Vancouver at Z-Space to finally code some prototypes of music related apps that I had in mind for the AT Protocol.
Today I present a first version of what I consider the groundwork on which we can build a more decentralised music streaming ecosystem that empowers indie artists and labels. The prototype can be found at alpha.indiemusi.ch
One of the basic principles of the AT Protocol is that users' data and the applications that represent these data in user interfaces are separated. The user's data live openly on the Personal Data Server (PDS) and can't be controlled by a single app. This gives artists and musicians more ownership over their social media content. What if we apply this principle to the core business of musicians: their audio files? What if the album releases and tracks lived on the PDS too and streaming apps have to pull it from there?
This gives more agency and ownership to the artists. Instead of uploading their whole catalogue to a dozen different streaming apps, they only have to do it once and they can give different streaming apps the permission to pull their catalogue from there. The landscape of streaming apps can evolve over time, but the artists stay in control over their catalogue. They can withdraw their releases from the apps that they don't align with any more. Streaming apps can have different business models and artists can choose which ones suit them and their core audience best.
I see one big challenge if we allow all artists to upload their songs to their PDSs: how do we do this without creating a data jungle and a copyright nightmare?
The prototype that I present today is rooted in my experience of running the indie label Red Brick Records, an artist owned cooperative from Switzerland. Because our financial coop model is based on collecting publishing royalties, we pay a lot of attention to the precise administration of our artists' catalogues. Therefore, I propose a list of ATProto lexicons that invite artists to record all the metadata of their releases right away in its most complete and precise form.
The different data types might look a bit overwhelming for technologists who are not familiar with music business and copyright, but this proposal is based on my best knowledge of how this works in our label setup.
An important concept to understand is the difference between a song/composition and a recording of this song. The song is the more abstract representation (the melody, the chords, the lyrics,...), while the recording is a specific, fixed performance of this composition. Often, the rights about the song and about the recording belong to the same people, but this is also often not the case. A cover song is the easiest way to understand this difference: Artist A covers a song of artist B. Artist B still owns the copyright on the song, but artist B can earn royalties related to the recording.
That is why I propose different lexicons for recording and song. It is also a reason why I propose 3 different actor types. A publishingOwner is someone who owns the copyright to the song, typically a songwriter or composer, but it can also be a publishing company. On the other hand, the masterOwner holds the rights to the recording. There is also an artist actor lexicon, but this has generally not a lot of administrative importance, it is more like a 'brand', how the authors/composers/performers are generally known by the public.
I added fields to those lexicon schemas with identifiers which are important to the music industry in general and copyright collecting societies in particular. As a songwriter I am registered with the Swiss copyright collection society SUISA, and I am known in the international network of collecting societies by my IPI number 01145982828. All the songs that I registered there also have an internationalised identification number, called ISWC. Once I recorded the songs, they were registered by my label Red Brick Records, who assigned ISRC numbers to the recordings. On an administrative level, Red Brick Records is the master owner of those recordings. When I released a set of recordings, they were gathered as a release , which is a 'sellable product'. This can be a vinyl album or a cd, but also a digital release, which all get a GTIN number.
You can find examples of these types of data in my personal repo in the at://did:plc:giaakn4axmr5dhfnvha6r6wn/ch.indiemusi.alpha namespace.
I created records for myself as the artist 'Hilke', as the publishingOwner Hilke Ros, but not as a masterOwner, because it is my label Red Brick Records that is the master owner of my recordings. However, the label also has an atproto account under did:plc:wkatvmhpoodroywh52bbemeh (redbrickrecords.bsky.social) and created a masterOwner record there. The label is at the same time a publisher and created also a publishingOwner record with their own IPI number. This made it very easy to add them in the interested parties list of my songs and as the master owner of my recordings. Because their IPI number was registered on their atproto repo, the app autofilled their IPI number into my song records. My producer Anna Murphy also owns a small percentage of rights to my songs, but because she doesn't have an atproto account yet, I filled out her IPI number by hand (each and every time...).
Like this, I managed to register all the data about my last album 'Am I Angry Enough?' in a very complete way, and all the parties in the monetisation chain of my music are already written into the protocol data, before any streaming service can start to stream it and build a business model on top of it.
What's next?
This is only data, the most important thing is still missing: the music! In the next phase, it should be possible to upload the audio files corresponding to those recording records onto the PDS. However, since files uploaded as blobs to the PDS are public, it would be easy to just download the music and that would make it problematic to monetise the music and make a living as an artist. Therefore, we need some form of permissioned data for the audio files, an issue that is still open to resolve on the AT protocol. My idea is that streaming services that want to offer releases of artists on their platform need to make an API call to indiemusi.ch, that prompts the artist to create a release permission grant to the service, which is also stored on the PDS. This gives the streaming service the permission to download the audio files and integrate them in their streaming offer. As soon as the artist deletes this grant record, the streaming service is no longer allowed access to the music.
Another path that I want to explore, is mutual verification of the data, between artists, songwriters, labels, publishers and even collecting societies. This would almost be a 'like' of the data that is recorded in the repos by individual contributors, a check mark that confirms: "this entry is correct". This would build more trust in the quality of the data and can give upcoming streaming service builders more ease of mind that they are not trying to build a business on top of copyright infringing material.
What are your thoughts?
This is just a prototype to make some of my own thoughts tangible. Please reach out to me if you have any feedback, if you can think about improvements, or if you want to build a streaming service on top of this concept.
Now that I have some UI to show, I will also start to reach out to artists, labels and copyright collecting societies in my network. I hope this is something we can build together as a community of artists, labels and technologists.