Building Identity, Authority, & Trust Into Songs — One Link at a Time (dotBC Update #6)
We are now entering a major turning point in the Dot Blockchain Music project’s short and exciting life, as we are about to embark on phase two of the proposed development work, in conjunction with major and independent partners in the music ecosystem. Together these next deliverables represent most of the plugins and interfaces needed to make the system we outlined actually work for the music industry. We anticipate about three to four months worth of development work in this next phase, and are excited to share the results with you as we develop additional code and bring on new partners.
In the meantime I thought it best to answer one of the many questions we get on our slack channel and in person, and this is one that relates to Identity, Authority, and Trust in the Dot BlockChain Music architecture. In essence, there are two very important validations that are core to dotBC: user identity and song identity.
“Trust me, I’m from the Internet”
User Level Authority
As mentioned in a previous article, the dotBC architecture works in a similar way to tagging on a social network. As such we believe that trust, authority, and identity will be established and maintained in a similar way, but with some added dimensions that I will lay out shortly as they relate to both a blockchain environment and interoperability in music (as well as any other mediums that relate to content owned by multiple parties).
Today millions (if not billions) of people use Facebook, Twitter, Instagram, Linkedin, or Google to log in to websites each and every day. Some of these sites require two-factor authentication, while apps like Authy and others are used to confirm and verify identity at a (sometimes annoyingly) regular rate. Meanwhile, device level authentication is thankfully becoming more commonplace, with, for example, the fingerprint being an identifier in both Apple and Android Pay, and greatly speeding up identity management. This means, due to its extremely complicated nature, that we do not need to reinvent the wheel for dotBC, as we intend to leverage the difficult work that best-in-class digital identity tools have already developed over time.
At the same time we also see no reason to enforce a unilateral authentication and permission method on users of the system once it becomes public. We feel that this would limit the ecosystem’s ability to grow and evolve on its own. However, it is crucial in this initial phase of adoption that we balance this open architecture with the need for parties using it to be recognizable to each other, to know who performs which function, and to balance and leverage the public and private nature of a blockchain technology. As such the dotBC application will require multi factor authentication to get into the desktop app, and therefore to work with and manipulate dotBC bundles. For those to whom it is relevant, domain name login (@recordlabelname.com, @artistname.com, etc.) plus, where relevant, social network (Facebook/Twitter login) validation will be used to identify who the parties are and what actions they can perform. We do not intend to enforce or validate identity within the dotBC live environment (i.e. once out of this initial alpha period) and this is partly why we are looking to get as many known entities signed up as early as possible.
To get to a verified and trusted identity, or as we call it “User Level Authority” in the dotBC system we propose a lightweight and staged process to get to a trusted authentication for users of the system.
Verified authority could be reached, for example, in the following way:
- Two-factor authentication, i.e. reply to a domain-confirmed email and respond with short code by text = 25 points
- Social network logins, Facebook, Twitter, Linkedin etc. with different weights set against each network = 25 points
- Accepted and reciprocated linkage to other known parties to the system, i.e. publisher, label, performing rights organization, digital service provider (supporting social login or oAuth), distributor, digital audio workstation, or other verified user such as engineer, producer, co-writer, musician, etc. = 25 to 50, points depending on the “depth” of the linkage across organizations.
- Registration or identifier from a recognized ISO standard for authors and entities (i.e. ISNI) = 25 points
In essence, user identity will be on a points system, which will allow all participants in dotBC to determine their own identity thresholds for their uses, and possibly tier their access and transactional operations based on such an identity model. This scoring system will also allow users to look at how good the User Identity score is RELATIVE to other users in the dotBC system. We have chosen this approach as it is a combination of what is already working on the web, but also because we view our partner plugins as the true gatekeepers to authority and identity across their shared dotBC system.
“Trust me, I totally wrote this.”
Song Level Authority
In addition to User Level Authority we also propose a system that we call “Song Level Authority.” We propose that each song on the writer’s side and on the master side be given scores (similar to the identity score) and that these be used to settle both destiny and ownership should conflicts arise. We have previously discussed the requirement for “Minimum Viable Data” for a song file to enter into the dotBC environment, so that is presumed to be correctly provided as a starting point.
The dotBC architecture allows for ownership scores to be represented before a song could be (for example) sold or licensed in perpetuity, retitled, or altered substantially in any way.
dotBC would not mandate what these percentages would be long term for any specific use (as we feel that this should be left up to authenticated users in the system), but we would assume and or advise that a minimum of 51% of ownership would be required to make any substantive changes to a song file on both the master and composition aspects of a song.
One use case could be, for example:
- Chris and I write a song together and record it on Chris’s workstation.
- I ask Chris to send me a copy.
- Chris, in order to export the song as a dotBC bundle, enters that he is a writer of the song and that he represents 50% of it as a writer and adds a title and our band name.
- Chris then tags his publisher and his Performing Rights Organization (PRO) through their plugins and then tags me as a co-writer. His publisher and PRO now know, and can validate that this work exists, and I can choose to agree with Chris’s 50% claim, disagree, or ignore it, and all above can see the same set of entries in the blockchain.
- If I agree with it then we have a 100% match and I can then tag my PRO and publisher, label, and any other parties, and all changes and amendments are tracked through the blockchain ledger via the dotBC file.
Of course the above is a simplified workflow but the same principles would apply in the case of multiple writers, publishers, sub-publishers, labels, territories, etc. Each party to the song and each identifier (ISRC, ISWC, IPI, ISNI, etc.) adds to the robustness of the truth within it, and the plugins attached to the song can choose what level of Song and User Level Authority to accept when contracting with the parties to it. We are currently working on a preliminary scoring system to allow for a song to have a “dotBC score” based on key attributes and linkages across the dotBC environment that will allow for any participant to determine easily how healthy the song file, metadata, and ownership information is RELATIVE to other dotBC bundled files in the system.
We also have in place a mechanism for representation of a song by third parties. For example, an artist in the dotBC system may be represented by five members of a band, but may choose to allow their manager to speak for 100% of the song. This manager as a result of said authority may in turn choose to allow the label to speak for that 100% with pre-agreed exceptions and exemptions hard coded into the song itself, such as contract end dates, pre-agreed usage stipulations, and moral exemptions on song exploitation.
In addition, dotBC will facilitate non-authoritative attribution of co-creators (session musicians, engineers, producers, etc.) to be managed at the song/session level in a similarly collaborative way.
Publishers would have these same types of song level permissions available to them on the composition side as performers would on the master side.
“But what if I lied?”
Disputes Involving User and Song Level Authority
One of the most important things to remember about the dotBC system is that lying isn’t something that you could or would want to easily do, due to the truly public nature of the shared minimum viable data registered on the blockchain. User and Song Level Authority will become almost like a credit score across users, songs, and catalogues, with thresholds needing to be met by the plugins that serve the end users.
To use a simplistic example, let’s say that I was fraudulently trying to claim 65% ownership of a song that is already in the system with 50% ownership registered to our co-founder Allen, and authenticated by linkage to his PRO and publisher. I would need to produce some kind of proof to my get my PRO and publisher (if I had one) to support my claim in order to make this change. I would then need Allen’s parties to agree to lower his 50% of the song and amend the Blockchain record for all to see. Then all of the linkages and amendments previously made would be available to all parties to view time-stamped in the ledger. It is more than likely that these types of disputes would be handled offline as they are now, but with the key difference being that in the dotBC system, if the above example were resolved to a 50/50 split between Allen and I, plus all parties moving forward, would be able to see this in the same place and corroborate it, making ownership stronger with every verified link and amendment added to the songs data.
In another scenario, let’s imagine that our co-founder Bill is trying to upload, register, and claim that he has controlling Song Level Authority over his favorite Beyonce song. At the point of upload, the audio would be scanned (as all works would) against existing databases of works (Gracenote, MusicBrainz, Dubset Media, etc.) to see if it already exists. If found, then Bill would be offered the chance to make a claim against it in order to move forward and then the process outlined above would begin.
But lets imagine that Bill (with his usual cunning) has altered the song just enough to get the song through those filters. He then has to link to the appropriate plugins in the system needed to get to a state of distribution. He’d need to create an identity as Beyonce, and link to PRO, publisher, label, distributor, etc. in order to get the track out into the world and to make any money from it. In other words, it is highly unlikely that digital service providers, PROs, labels, or distributors would all align (or even be able) to confirm Bill as being the authentic creator of the work in question. Add to this the ability for catalogue owners to be able to do searches through their system, by title, artist, etc. with allowances for spelling errors/variations, etc. and that if you were to catch something really similar, begin the process of dealing with Bill’s shenanigans as you would with today’s existing conflict resolution tools.
Other real world and current day scenarios that we can see this fixing could include labels claiming that they own rights in territories in which they do not, or publishing companies acquiring catalogs and automatically assigning 100% ownership of all of the songs to themselves. In a system in which all the arguments resolve back to all parties to the songs themselves (but into a single ledger), these bulk actions become harder to execute, as Song Level Data would be genetically embedded into the tracks in question. Disputes that resolve in one place are resolved in all places.
Longer term we envision companies like Spotify, SoundCloud, YouTube, and Pandora (through their plugins) mandating that they will only accept songs into their systems that meet a threshold of truth that could include a valid User Level Authority score equal to no less than the 75th percentile, relative to other files, and a Song Level Authority minimum of the 85th percentile, relative to all songs in dotBC, including one verified PRO + DDEX metadata alignment. Once again, it’s not in dotBC’s mandate to decree what those thresholds should be, but to facilitate their creation. As such we believe that data persistence in a blockchain, informed by Song and User Level Authority, will lead to a single decentralized place to validate Identity and Authority at the song level, and thereby create greater trust among those who today do not always trust one another.
As promised, our public webinar (non-technical) will be held on Monday, November 7th at 11:30 a.m. EST. You can register for it here. As for the technical webinar, we will be sourcing questions in advance here.
Your_song_name.bc
Early access
Since many of you have expressed interest in getting your catalogs into the dotBC ecosystem, we are pleased to announce that we will shortly be opening up a priority queueing system. This means that you, or your organization, can get early access to the public release of our bundler application and the plug-ins. As part of this early access process, you will also have the chance to upload to a private FTP server a sample of your metadata, media, and/or documentation. This initial upload will be for research purposes only and will not be registered to any blockchain, but will allow our engineers to to work with the type of real world data that our plug-in system will need to handle. Based on the size of the catalog and the quality of the data uploaded, we will also invite a few of you to participate in some of our beta programs, so stay tuned for the release of this queueing system!
Sign up for the email list or request slack access here
Our Website is: www.dotblockchainmusic.com
GitHub: www.github.com/dotbc
Our last public webinar here from Nov 7th 2016 is here and our technical webinar from September 28th 2016 here.
