Subvert – Collectively owned music marketplace

They create a new address and from it they publish a revocation of the old address. Then they re-register their content and associate it with payment patterns that pay out to the new address. Then they propagate the new address in-person. When fans trust the new address, their client notices the conflict and they're prompted to prune the old one (since the trust-score on the new one is higher).

If the artist-fan-trust-relationship is multi-hop, it may take a little while for the switch to propagate from fan-to-fan rather than from artist-to-fan, but when it does they'd be notified to consider making the same change.

Meanwhile, a timer has been going since the last time the artist collected funds from the account with the lost key. Once it gets suitably high, the pending payments into it are reversed back to the fans, and the pattern is altered to exclude the abandoned address and notify payers that they might be a better pattern to use, prompting them to find and use the new pattern.

It's not the simplest way, but it's the best I can do without having anybody on payroll, which means maximizing the amount received by the artists.

Besides, art is supposed to be transformative, not status-quo preserving. Even though 99% of artists don't have to worry about being censored directly, I think they're more likely to be interested in protecting the 1% who do. That means having both groups using the same payment rails, and they must be rails that don't respect the kind of bullies that freeze accounts based on content.

Finally, you can lean on this web of trust for the distribution of things like concert tickets, making life more difficult for scalpers (and you can identify the scaplers who have infiltrated your fan network, and explicitly distrust them for next time).

> Once it gets suitably high, the pending payments into it are reversed back to the fans

So basically: you're screwed.

> Besides, art is supposed to be transformative, not status-quo preserving.

Blah-blah-blah. I would really love to belong to a collective that puts my music right next to CSAM. Fans would really appreciate it. So now you have to have an enforcement mechanism, like voting. What if somebody hacks enough keys to take over the voting? Have even more privileged members?

That's the thing: the real-world complexity has to deal with all kinds of edge cases. And we have a legal system for that, with several thousand years of legacy in it.

What do you mean "next to"? You provide a file, the system gives you a way to pay the people who made it and a way to prove to others that you've done so. If you keep CSAM next to your music, that's on you.

So each musician has to keep track of everyone's else tracks? Including key changes? Or is there an organization that manages it?

What if an actor disappears and the timeout makes all the tracks unavailable until they are re-uploaded with a new key?

I can go on indefinitely. There's a reason "smart contracts" are now just another way of saying "scam", and why blockchain is only seriously pushed by scammers and criminals.

How to move around the content isn't really a problem I'm trying to address. As far as I can tell it's a solved one, has been since Napster. Different users like to manage their media differently, I'm not going to tell them how to do that.

Same thing for managing user identity. Whether you want to build an organization around that problem or slap together a CLI and let the users fend for themselves, again not something I'm trying to weigh in on.

These are app-level decisions, not a protocol ones. And neither of them really lend themselves to on-chain solutions.

The unsolved problem I see here is that you've got a community of users, all with identical copies of a file, and they want to build consensus on how that file should "cite its sources". In the case of music, that's a bunch of fans wanting to pay the musicians, but it's structurally the same as if you're trying to give feedback to authors of a paper or claim that researcher X found vulnerability Y in code Z: you're building consensus on a directed graph between datasets and actors such that other actors have something to reference when they communicate (or send payments) to each other about those things.

That's the only part of the problem that's likely to come under attack by incumbents, so it's the only part you need a ruleset and computational verification for. Everything else can be handled "the normal way", by appealing to the good behavior of the incumbents.

People (e.g. Sony) are going to try to get paid for music they never played. People are going to take credit for research they didn't do (or did poorly). People are going to try to misrepresent the trustworthiness of things that they built and want to charge you for.

You can't put that on AWS because nothing on AWS is more trustworthy than its least trustworthy admin. You can't leave it to the courts because only the powerful can use the courts to their advantage, for the rest of us they only serve as a system for mutually assured destruction.

Which people get credit for which data is too contentious of a topic to trust to the hands of people who have pinky promised not to use it in their power games. If it weren't, there'd be no reason for Subvert to exist in the first place. I hope they can manage it by just being very careful about how they allocate trust among their owners, but history has given us centuries worth of reasons to be skeptical.

Meanwhile, other data that the powerful would prefer to tamper with remains intact in the various blockchains that protect it. The rules continue to be followed. There are a lot of problems with that space, especially at the interface between the rules-governed parts and the pinky-promise parts, but we've only been chipping away at those problems for decades. They feel a lot more tractable than anything involving the insufficiencies of the law.