mediachain / apps

Discussion and documentation of apps built on Mediachain
15 stars 5 forks source link

Music app idea: Pay artists for music directly #1

Open jessewalden opened 8 years ago

jessewalden commented 8 years ago

IDEA: Play to pay music (directly)

Extracted from 7/11 MIT Media Lab (Digital Currency Initiative) x Mediachain Brainstorm Doc: https://docs.google.com/document/d/1Ke0ivPo7GZXHVEU0oV1q2IeWOUJ_ZkcHi95EqWsDxBk/edit

Consumer Description:

“A way to support the artists who’s music you listened to directly”

Technical Description:

System for identifying a song, looking up associated payment terms (Bitcoin address?) and remitting payment. Fingerprint/Keyword Search → Mediachain Identifier → Bitcoin address

Thesis:

The music library is a commodity, abstracted by new UIs (e.g. Echo → Spotify/Pandora/Amazon) An open, decentralized library allows for more innovation (new UIs), and more direct relationships between consumers and creators/rights owners.

Related projects:

ProTip (Journalism) Ujo

Music app stack (top → bottom)

jessewalden commented 8 years ago

Was really pumped on the way back to NYC, so I worked on a wireframe of what the end-product might look like. Definitely some imagination + feature creep here, but this may be a good artifact from the discussion, and a pillar to work backwards from as we define the MVP and implementation strategy.

muse wireframe

narula commented 8 years ago

This is awesome! Some questions to think about:

Does it make more sense to frame this as tipping, and pay the artist directly, or to actually try to pay the appropriate people who own the rights to the content? I can see pros/cons to both approaches; tipping is just easier, but it might make the rights owners mad.

I think it's important that we remove as much responsibility for ourselves as possible in the flow; we should make it as easy as possible for people to claim their money, and I want to hold private keys for as short a time as possible. This raises a question -- how do we get the private keys to the artist? Thought: attach bitcoin addresses to verified twitter accounts? Use keybase.io?

jessewalden commented 8 years ago

Does it make more sense to frame this as tipping, and pay the artist directly, or to actually try to pay the appropriate people who own the rights to the content? I can see pros/cons to both approaches; tipping is just easier, but it might make the rights owners mad.

Yeah, there's ALOT less complexity in tipping (don't need to know the license details) and it's a linear progression to jump from tipping to more complex payments by adding payment terms as metadata hooked to canonical IDs.

Tipping also fits the consumer story: the service needn't purport to replace existing streaming services. Instead, it can opt for access to the binary media from services users already subscribe to or use like Spotify, YouTube etc — it's for hardcore fans who want to supplement an existing streaming service/payment to reward the artists they actually listen to, directly (a tip).

I think it's important that we remove as much responsibility for ourselves as possible in the flow; we should make it as easy as possible for people to claim their money, and I want to hold private keys for as short a time as possible. This raises a question -- how do we get the private keys to the artist? Thought: attach bitcoin addresses to verified twitter accounts? Use keybase.io?

Agree. I think Onename and Keybase have the best UX for associating a social account with a Bitcoin address. For example, if the service holds a key for Taylor Swift, and we trust @taylorswift13 is the real deal, then she simply needs to post a Bitcoin address on that Twitter account to make the association, the service can transparently send all funds collected to the address she posted on Twitter, and update the address in Mediachain accordingly. Even better, she can update the payment record in Mediachain by making a statement signed with that key.

ronoc commented 8 years ago

This might be slightly off topic on this issue (and may in fact belong in an issue of it's own) But I think it's a good idea to consider the role of the royalty collection agencies (PRS, ASCAP etc). Even though some might consider them to be largely irrelevant considering the way it works right now they do hold important relationships with the large payout organisations like BBC and other media outlets. When I say large I mean for the artist these royalties can be much more significant than what the new age streaming services pay and are therefore (in the minds of the artist) more important.

And this is where this technology could really help the old industry modernise. But yeah sorry back on topic. The idea of tipping through a client side plugin is nice, but I doubt that it would ever gain too much traction. However having the technology embedded in existing streaming services sounds much more appealing. So here is the question, what is the incentive for the large streaming services to ever embrace this technology ?

jessewalden commented 8 years ago

@ronoc i think there's still a role for PROs like ASCAP, PRS etc -- someone still needs to validate claims, and facilitate conflict resolution in an open system like Mediachain.

the intent with this product brainstorm isn't necessarily to get massive adoption or integrate with existing services, but instead give a a really compelling demonstration of what one can build with open music metadata, content identification technology and cryptocurrency.

JENKOio commented 8 years ago

to get a massive adoption, you need to develop Network. My Idea is to Play Music Vs share privacy. If you don't want Add, you have 2 options: whether pay a fee (such as Deezer) whether share with your contacts. In the second option you will get more user privacy. in such case, the quantity of Hyperfans will increase (according to The curve from Nicholas Lowell ). Those Hyperfine are able to pay, So what? you need to engage them.

mrtoddalexander commented 8 years ago

Maybe add Alexandria.io to the "Related Projects" section?