STOP TRYING TO PAY ME AND PAY ME! — Music on the Blockchain for Songwriters, Artists & Managers (dotBC Update #5)
(For a more detailed history of the project please see previous posts here)
With most of phase one of the dotBlockchain Music project sitting in GitHub and phases two and three underway, I thought it might be a good idea to write something more practical for songwriters, artists and their managers. The journey from blog to code has been an amazing and eventful one and I am pleased to say that we have had broad industry buy-in to explore, test, and even implement this idea that has been keeping us working mornings, nights, and weekends for the better part of year now.
To unpack in a more practical sense what we have built and shared with the music community, I thought it might be helpful to outline some workflows that songwriters, artists, and managers will experience as the ecosystem evolves, with the trick being to begin the dotBC creation process as close as possible to the writing and recording moment — no matter how rough or early a version may be.
Creation & Registration:
In its simplest terms to create a “your_song_name.bc” file for initial registration only it must contain no less than:
1. The information of at least one of the writers of the work
2. The information of at least one of the performers of the work
3. Its name.
4. A music file in any of the standard formats, i.e. WAV, MP3, AIFF, etc.
We call this Minimum Viable Data.
This means that you would not be able to create a “your_song_name.bc” file with less than the above, and this would be considered a song ready for registration to the Blockchain and for sharing privately. The information about the song (not the music file) would be publicly available and it is our goal that the workflow to take this first step will be built into every digital audio workstation that a creator might want to use. In fact it is our goal that there would be no way to simply create a traditional export of an MP3, WAV, etc. minus this basic core metadata.
The above outlined is clearly barebones, and this is intentional. We tried to look at something that was practical and easy, and also that could, if all else failed, identify the two most important participants in the creation of the recording, and link them back to what the song actually sounds like.
Linking and Tagging:
Our technical lead Chris has a wonderful analogy that I am pleased to share with you about how songs become interoperable in the dotBC ecosystem. He likens the process of linking songs to tagging photos on Facebook. When a friend tags you in a photo on Facebook you have three choices:
1. Ignore the tag
2. Accept (i.e. Agree) that this is in fact you in the picture
3. Dispute/Deny that it is you in the picture
In this sense we want to make the data around who owns what shareable publicly, and who has permission to do what in a musical work, operate in a similar way but with with the added dimension of hierarchy or authority.
In a simplified example: if today Chris and I both write a song on his workstation and he wants to send me a copy, he exports an MP3 or WAV file (perhaps with ownership metadata included, perhaps not) and we would then need to go through a process of sharing it with our managers, bandmates, musical collaborators, etc. any of whom can alter the metadata and duplicate it with that same data altered at any time. One of us would then need to register the track with (if applicable) our publishers, PROs, labels, etc. who as discussed can make copies, add or subtract information, and who do not share any kind of common database at all. In fact, in the case of most of the parties mentioned, they do not even require a recording of the song to know what it sounds like. So in short anyone in the chain can alter the work, and there is no central place to corroborate or to affix data in any kind of a permanent way at any point, since the format (MP3, WAV, etc.) is in and of itself unstable. There is also no place to view, track, or propose any changes to the files themselves, since they have no permanent truth or home.
In the workflow of dotBC, with the above scenario, when Chris wants to send me a copy of the song, he has to enter the basic Minimum Viable Data outlined for the song, in order to export it from the work station to send it to me. Once entered, he can then send me the “song_name.bc” file containing either the music and the metadata he has just entered, or just the data with permission to unpack it into the full song from his workstation or cloud. The information he writes into the file is expressed into the Blockchain at the point of export to create the record that it happened and that he was the one that created this at this time and in this place. In short he’s creating the genesis block or first line of information in a changelog that can be amended forward from that point on, but whose history can never be deleted.
Chris could also “tag” or add me as a writer, musician, performer, engineer, producer, etc. of the work, either before or after sending it to me, at which point I could choose to:
1. Ignore the tag and not claim ownership or collaboration
2. Accept it as correct information
3. Dispute some or all of what he has expressed into it.
If he tags me as a writer for example and is claiming 80% ownership of the work, I would be able to see that and dispute it with him directly. Likewise if I suggested a percentage that he did not agree with he could do the same with all amendments being tracked.
But it doesn’t stop there. Once we have created an ownership hierarchy, Chris can then tag his publisher and I mine. Either publisher can then tag or link to our performing rights organizations if they are different from one another, and each time a tag or link is created it amends the Blockchain’s record to reflect the new truth as it is expressed at that current point in time, thus creating an immutable change log for parties involved in the song to see and interact with in one single place, but in a decentralized way. We also see this as a way to drive adoption.
Authority
Simplistically speaking, we envision that Authority in the context of dotBC files will have a number of flavors by nature of the fact that it is not the place of the dotBC architecture or team to dictate what percentage of ownership would be enough to authorize actions as they relate to the work. We believe that this should be handled by the participants to the work itself. The architecture does allow for owners of the works to be permissioned in at certain percentages and for changes of ownership to take place at rules set between the various parties or plugins to the song, but we did not want to hard code or enforce specific rules. It is my belief that end user plugins like Streaming Services, sync licensing agents and the broader market in general will choose what levels of truth encoded at the file level are acceptible for them to want to work with.
Managers, Publishers, Labels, Performing Rights Organizations and Digital Service Providers as Plugins:
As the song progresses from its first Minimum Viable Data set and more complex and richer layers are added, parties to the song can tag/link their works to their labels, publishers, performing rights organizations, and ultimately to services like Spotify, YouTube, SoundCloud, Tidal, and Pandora, among others. We call these parties to the song “plugins.” These parties can be given digitally expressed permissions set at contract terms, and managers can be assigned permissions to grant rights and licenses to these parties on behalf of their artists and writers at will. Works can be linked to services that choose to build, or have built for them, plugins that would add things such as audio fingerprinting, geo-tracking, data clean up, distribution, registration, identity management, search, etc., all using the same tagging logic outlined above. This will all require great approve-and-deny workflows, and it is great to see some of the private companies who already offer these types of services, preparing to build plugins and offer them to users of the system both commercially and for free. Think of an Apple/Google app store or Chrome/Safari extension gallery, but for services around songs and catalogs instead of around an operating system or browser.
Don’t these files get really big and confusing?
Regarding file size we have designed the system so that the source or genesis dotBC file could contain, demos, session files, stems, lyric PDFs, artwork, live versions, covers, and remixes, etc. So yes it could get very big indeed. The architecture accounts for this through a process of “minifying” and “reifying” as a way to share what needs to be shared between parties to the song.
So an engineer for example who is looking to share a new mix with the artist she is working with could send over a tiny “minified” or stub version of the file containing only the metadata and instructions. In other words, the “your_song_name.bc” file that she sends allows for the transport of both permission and instructions on how to unpack or “reify” a larger version of the song from the engineers dotBC desktop or cloud. This same process could be used for delivery to digital service providers, distributors, or labels once the required threshold (DDEX, etc.) for ingestion has been reached.
Regarding confusion: if you break it down, the purpose of the system is to get to the highest level of truth possible at all times into one permanent decentralized place. Due to the centralized and non-interoperable state of the music industry today, any change to a work no matter how small has to be pushed outwards to hundreds of different destinations. These silos have little to no common or open and searchable registries to corroborate or unify musical work, and in some cases are using data formats that were created in the 1970s. They also have zero impact on files already out in the wild, on people’s hard drives and on YouTube, etc. But with dotBC any changes to the work are viewable in the changelog and are accessible to all who run the system and updated as the Blockchain syncs. Disputes that arise between parties to a song are settled and solved at the song level and then broadcasted to the network. So a streaming service, publisher, PRO, or label could simply query (through their plug-in) the song to see if its ownership percentages and/or payment terms have changed since it was last accessed.
Essentially this song level data creates a type of marketplace in which optimizing data leads to greater interoperability, and therefore expanded and accelerated, routes to monetization for the works themselves.
Digital Rights Expression — STOP TRYING TO PAY ME AND PAY ME!
Imagine a music ecosystem in which a music supervisor could discover a song she liked on the steaming service of her choice, and through that services plug-in, access the digitally expressed rights enshrined in the dotBC file — then, providing they matched the use case required, she could deal directly with all parties involved in the license of the song from the song itself. Including payment terms, region, availability, etc.
A sync licensing plug-in (as proposed on the public Slack Channel) could be built to allow for filtering of use cases or song attributes, (lyric type, genre, tempo, territory, price, etc.) that would in turn allow for a more seamless and accessible way to get approvals in a hurry and people paid faster. The power of having access to this basic DNA of ownership will radically improve the way in which money flows to those who are rightfully entitled to it.
Digital rights expression into the format itself would mean that things like advertising, data collection, monetization, contact, and other preferences would simply become part of the fabric of the track itself. These expressions, when machine-readable, presuppose a world in which authorized parties will contract with songs directly, as well as pay at rules set by creators and their teams. Term limits and usage thresholds as well as changes to price points, can be hard coded and automated at any point by those authorized into the track, and then broadcast to the network as the Blockchain Syncs.
Today there is simply no tangible place in which to express that I, as the writer or creator of a song, do not wish for it to be used at, say, a white supremacist rally, or as the backing soundtrack to a cat torture video — and yes I’m sad to say that evidently both of these things do still exist. It therefore stands to reason that digital rights expression will also point to exclusions and exceptions, and so avoid situations in which political candidates use an artist’s music without permission to further agendas that are not aligned with the creator’s.
I’m not proposing at this point that this song level expression of intent should be legally binding, but I do think that being able to codify, into the song itself, certain attributes or intentions for the work would solve a lot of the problems outlined above. More importantly, I believe that song level rights expression will lead to a greater interoperability and therefore more monetization possibilities for the work.
Practical update:
The dotBC team is actively working with major and indie labels, publishers, performing rights organizations, digital service providers, and, most importantly, songwriters, artists, managers, and trade groups, to educate, involve, and build the plugins and extensions needed to propagate the system. In the next few weeks we will be posting to our public slack channel and email list details of how to get your songs into the dotBC format. This will happen in a closed system for now, and we will shortly be publishing our Minimum Viable Data document. In the coming months we expect the first plugins to be deployed onto the system, many of which we have been asked to build, but most excitingly many of which are being built by others independently of us. Anyone wanting to build a plug-in or have one built can get in touch through the email list or through slack, and any artist, songwriter, or label wanting to get their music into the system can let us know via the aforementioned channels. We will (in the order signed up) send over instructions as to how to make this happen. This is an interim step while the coding and fundraising continues, and we want to make sure that everyone has equal access now while we are still in the test state, and that we are able to assign as much “authority” to known parties before it all goes out into the wild. This does not mean that we are an authority. It just means that we can guide early adopters toward becoming authorities over what they own.
Thanks for reading! Get in touch.
Loving your work
Benj & Team dotBC
P.S. we’ve been announced as a startup winner from SF Music Tech and we are nominated by Musically for a 2016 Digital Music Award!
P.P.S. You can check out our technical webinar here and we will be announcing the date and time of our non-technical webinar shortly.
P.P.P.S. We are looking to get to 1,000 respondents to take our survey — currently stuck at 390 — so please help us get the word out! Thx!
