Mapping out the onchain music ecosystem

...and arguing that it needs a Public Goods core

Introduction

This piece is an attempt to describe the goal that I am personally working towards for an “onchain music ecosystem”.

It is in some ways intended to be a bit of a summary of much of the writing that I have put out through this blog over the past 18 months, and also a bit of a call for action to other people with shared interests in seeing something like this exist.

There is a lot to discuss, this is a long piece. So rather than jabber on in the introduction I’m just gonna get right into it.

Defining the onchain music ecosystem

The image centring this piece is a diagram that I put together a couple of mornings ago. My fiancee woke up to me sketching out boxes in the air while in bed next to her; she sighed, tutted, and went back to sleep. So I got up, drew it, and tweeted it out.

As I said at the time, it is incomplete and probably inaccurate. But I think gives a good idea of the general sense of direction that I mean when I talk about the onchain music ecosystem. Specifically, a composable stack of Public Good infrastructure that connects creation and front-ends to provide an ever-expanding set of tools and services.

The sketch is limited by both my lack of creativity and inability to draw, I clearly did not inherit my dad’s artistic gene and my mum’s handwriting looks like the result of a pissed spider covered in ink. Add to that the years of slide production that strategy consulting drives into you, and the above is what you get. Sorry.

To this point, clearly, an ecosystem is not the linear flow that I drew. It’s a möbius strip. A front-end, as defined below, often also facilitates a creator’s “minting”. And round and round we go ad infinitum.

Assumptions

This sketch of a future ecosystem is reliant on a number of assumptions that I hold, which are worth spelling out now for completeness and I will reference where relevant later in the piece:

• The onchain music ecosystem will live alongside and in parallel to the “traditional” streaming ecosystem

• Creators will be best served by playing in both environments, understanding that they offer different advantages and can be utilised symbiotically

• The onchain music ecosystem will not be specifically limited to “music NFTs”, as they have come to be understood, it is defined as any onchain activity related to actors within the music space

• The onchain music ecosystem needs to be built with a Public Good core, or else it will be sucked into the silos of the streaming ecosystem over time; this is ultimately our only defence to that inevitability

It is also worth noting that I see AI/ML/LLMs as a macro trend, with impacts to be considered as we would rising global inflation, increasing privacy regulation, and decreasing trust in political institutions.

As such, there is no specific reference to the machines taking over everyones’ livelihoods hype that seems to be sweeping the group think at the moment. Just be sensible when thinking about what this is saying and how LLMs may play into it.

Minting and Distribution

OK so, why are these separated from each other? People usually lump them together. Future “distro” does both, together, obvs…

Distributing music to the streaming ecosystem is fundamentally different to minting tokens into the onchain ecosystem. There are different requirements, different trade-offs, and different values that come from each.

Distributing music to DSPs involves a supply chain that registers and verifies your work and issues identifiers. The trade-off is that it is slow, restrictive, and reliant on 3rd parties.

Why engage in the streaming ecosystem?

A creator could decide that they don’t want to engage in the streaming ecosystem at all, and that’s fine. But, in doing so they are giving up on at least two advantages, one obvious, discovery, and one less discussed, third-party supported legal protection.

What I mean by this is that the act of distributing your music through to DSPs in effect brings other parties into the discussion to verify that this is in fact your music. To do so requires you to go through the various hoops that are designed to give enough confidence to the distributor that they aren’t going to get rekt by you releasing Beyoncé tracks under your own name, for which they are in part liable.

Releasing through the streaming distribution supply chain will ensure that your tracks and you get identifiers and registrations. But, you say, can’t blockchain do that also? Yes, but, there are two key challenges right now:

• One, anyone can mint a token, so how do I know that it’s your track that you’ve associated with it? The old-school supply chain has built a risk-insurance system for this with KYC at its core. We don’t have anything for this yet in the onchain ecosystem, despite advances in things like verified credentials and ‘passports”.

• Two, anything copyright assign-y, legal, requires paper contracts in place. And at that point then the blockchain element loses its point; if it aint enforceable onchain then it’s an appendage. Yes, there’s the whole “let’s make smart contracts legal contracts” argument, but, it’s not 2018 anymore so let’s just move along from that, yeah? Even if there’s validity in those claims we’re decades away from universal acceptance.

In the future, I see distributing into the streaming economy as a necessary step for a creator to build offchain proof points with 3rd parties in the legal ozone layer that surrounds everything.

Why engage in the onchain ecosystem?

This piece holds some assumption that you, the reader, are already bought into at least some of the benefits of building within the onchain ecosystem. And so it would be somewhat redundant to make a long case for it; I have previous blogs on some of the reasons why a creator would pursue this path.

In addition to the arguments made in those pieces is the specific value that you get from minting into the onchain ecosystem by being able to release whatever you want, whenever you want, without relying on 3rd parties to do so, and free of the restrictions that this brings. You don’t have to wait for an identifier to be assigned, for a distributor to deliver your track to a DSP, for the various rights to be cleared. You are still gonna be liable down the road if you are a bad actor, but the point is that you can do it.

Onchain x streaming distro?

By this point I’ve hopefully convinced you that these are different things, and both are important. But can’t they still be done by the same party? Yes, but, expertise, reputation, and risk mean that it is likely in the short-medium term they are better served by specialised entities.

More specifically, distributors could move into providing minting as a service for their artists, but in doing so open themselves up for a level of risk that they may not be willing to take on as the flow will be outside of their usual level of control. Plus it would mean them moving into an increasingly commoditised service that is built around a DIY approach. They could, and likely will increasingly try to, offer minting as a service alongside distribution but I argue that this effort would be better served at the “data oracle” level of the stack (which I’ll dive into later in the blog).

Entities that are building out minting platforms for creators may also seek to move into the streaming distribution game, however, this too comes with challenges. Distro is a scale business, with extremely low margins, it’s very difficult to make run in a financially viable way and has seen large consolidation as an industry as a result. Furthermore it is gate-kept through the “preferred distributor” system that most DSPs now run, effectively introducing significant barriers to entry.

One approach could be a partnership model, say if decent.xyz and distrokid teamed up; both facilitating their part, with built in tools and shared data. I’d expect to see things like this happening as we move forwards.

Another thing to consider with this part of the stack is one of my in-going assumptions, that “The onchain music ecosystem will not be specifically limited to “music NFTs”, as they have come to be understood”. I.e., minting tracks will only be part of the activity, the minting process will extend to things tangental to the music itself. Which would represent an extension far outside of the expertise, reputation, and risk profile that would be comfortable for a traditional distro.

Tl;dr

Minting and Distribution are each individually important enough for future creators to engage with, but different enough to remain separate for the conceivable future.

Distribution provides support for a creator’s copyright (even if they are a CC0 maxi) and a route into streaming discovery, minting provides freedom and access to greater potential value.

There will no doubt be counterexamples to this stated rule of separate flows in the coming months, but ultimately I believe they are unlikely to succeed and the best approach for a distributor is to either partner with a domain specialist, and/or to work on solutions higher up the stack, at the “Data Oracle” level.

Public Goods Stack

At the core of this sketch for an onchain music ecosystem is a stack of composable “Public Good” services. It is the engine room.

I define Public Goods as services that are open and available, open-source, for the benefit of the ecosystem, but an important note to make is that this does not mean that there is no opportunity to build a business here.

A more complicated version of this sketch would show a universe of services connecting and interacting with each of the layers. For example, a company could charge for easy API access to the results of a Public Good indexer, provide guarantees as to data validity, or produce subsets of the the data outputted from the indexer that obey certain rules, e.g. CC0 only music.

An important definition of the elements of the Public Goods stack is that the infrastructure itself is credibly neutral and not owned by any controlling parties.

Indexing

I have written lots in the past about Public Good indexing and why it is so important for the music vertical; so let’s skip over the rationale and I’ll just link this tweet.

We are building neume as an example of what a credibly neutral indexer can look like, crawling directly from the chains and coordinating across communities to set progressing requirements as new use cases are identified.

One thing that you will note from the above sketch is that there is not only one indexer but multiple. It’s important for decentralisation’s sake that rather than having one single environment that is translating data onchain into something consumable by front-ends, there are eventually multiple indexers running in parallel. In this, I hope that neume will inspire other alternative approaches that carry the same credibly neutral values.

And in fact, neume itself should probably be subdivided into separate environments, so that any platform consuming the data from it can be selective about the parameters of what it wants.

To the best of my knowledge neume stands relatively alone in this part of the stack, other indexing solutions are either API-driven, controlled by a single party, or not specific to the unique requirements of the music vertical. I hope that there is greater development effort put into this part of the stack in the coming months.

A Public Good indexer should be open code that anyone can run and get the same results as someone else (idempotence), is credibly neutral in that it will not limit or suppress certain results (other elements of the stack should be utilised for this where operationally / legally required), and is the reasonability of a wide community to develop and maintain.

Agreements Network

This is where things start to get really interesting, and leans more into the work that we did at JAAK.

If we see the indexing level of this Public Goods stack as the cataloguing of events that happen on chain, then we can see the “agreements network” level as providing links between those events and entities within the ecosystem over-and-above what is discernible purely from onchain data without context. In effect it is the proof of social & business interactions layer.

An example. If a creator mints a token and wants to split revenue with collaborators, then in the current onchain stack implementation they are probably going to use something like 0xsplits as a simple splits tool. However, if there is one thing that we know about the music industries it’s that nothing quite gets the blood pumping like ownership conflicts and the process for their resolution. How can we know that everyone on those splits agrees to the amount that they have been allocated, and how can we know if others feel like they should be on the split but aren’t?

To be clear, and this is very important, there is always going to be an exit to the courts solution. If someone has sold something that they didn’t have the rights to, or not gained permission or compensated collaborators, then the settlement layer has existed for centuries. To this, some people will start bringing out the whole “crypto means anonymity which means that the courts play no part” malarkey, but this falls apart as soon as the user off-ramps value from the system.

In reality, the ecosystem that we are building will be alongside copyright, legal structures, not ignoring them. It makes no sense to expect a creator that wants to engage in the onchain ecosystem to give up their copyright protection.

The agreements network layer is the start of building far more complex and interesting interplay between entities within the ecosystem. It will allow front-ends to build more comprehensive monetisation mechanisms and give them greater confidence toward statements that are in the system.

The agreements network should have several properties as a public good. It should be credibly neutral in design and operation, i.e. the system itself should be open to all, not prejudice any parties, and be free from control of any centralisation effects. It should ingest and allow for the statement of claims between entities, and enable the staking of reputation and/or resource against those claims to surface conviction.

An agreements network should operate as a guide rather than a source of truth. It should have mechanics in place that allow users to make informed decisions based on the claims it surfaces and the conviction staked against them. For, dear reader, there is no such thing as binary truth in the business of claims between parties, only a weight of conviction on which we can balance our own decisions.

An important note though, an agreements network is not a copyright network (we tried that one before…). Copyright, at least in the traditional definition, is an offchain activity that involves paper contracts and is backed up by the courts. An agreements network should be ultimately only concerned with activities that are enforceable onchain, though can be informed by contextual data coming from offchain activities or otherwise.

This thing is gonna be hard to do, and even harder to do in a Public Good way. Designing a system that is open, not controlled by parties of delegated authority (which is how it’s done in the offchain world), but also useful and trusted as a system (even if each individual claim has a non-binary conviction score), is an intimidating prospect. Furthermore, it is only needed when the complexity of use cases hits a certain point. But, we should start thinking about it now, before we end up with a centralised solution by necessity.

Thinking long term, as with the indexing step, we should be seeking to have multiple credibly neutral agreements networks to ensure that we don’t end up in another situation of centralisation and then oversized control. But that’s a way off yet, just one implementation would be a good start.

As a final thought, in many ways, an agreements network is a logical extension of an onchain social network. Taking Lens as an example, within it we have the concept of entities, publications, and social interactions between them. It is not a massive stretch to see how this could be used as a front-end to build out a web of agreements and relative conviction towards the statements made between them.

Data Oracles

Data Oracles allow for offchain data to be brought onchain. This will be useful for our onchain music ecosystem by adding further context and validation to the events and statements being catalogued within the Indexing and Agreements Network.

As mentioned multiple times in this piece, we should not see the onchain and streaming ecosystems as competitive but rather symbiotic and in parallel to each other, serving different goals. Data bridges across the ecosystems will be valuable where they are informing activity.

This, for me, is the primary role that a distributor, rightsholder, DSP, data services, or otherwise has in the onchain music ecosystem. They represent the offchain interests of their clients, and provide that information into the onchain ecosystem, with their reputation as stake of the validity of the claims. This in turn, is a valuable service and represents a revenue opportunity.

The system of data oracles should be a public good, but to encourage activity should also include financial incentives for good actors.

In the interests of blog-length, I’ll leave this one here, but there is a lot to explore within this topic.

Data services: ID Resolution & Curation

I have put ID Resolution & Curation together as they represent data and signals that are generated within front-ends and then outputted back into the stack to provide greater context for the ecosystem. They are two examples of likely unlimited similar such services.

What I mean by ID Resolution is the idea that an artist, collector, or other, may operate with multiple different wallets and identities but wish to map them together once, within one app, and then for that information to translate through the stack. It represents a specific example of a pin point at the moment, but a good example of the power of the onchain music ecosystem built around composable services.

Likewise, curation, the idea that a user can collate lists in one place, output into the stack and then for that to be available to them and/or others in other front-ends is something that is difficult to do in the streaming / “web2” ecosystem, but an obvious example of utility in the onchain ecosystem. Next gen blog era wen? Check out Public Assembly for great work here.

In the first example, there are obvious management applications that can be built at the front-end, alongside the growth that we are starting to see in analysis tooling (e.g. Bello). It’s likely that as account abstraction starts to come through we will see some in-wallet solutions here, but, yeah, feels complimentary.

Anyway, the point here is that contextual triggers can and should be pumped back into the stack to help make the big soup of data make increasingly more sense. And these should be Public Goods.

Tl;dr

Public Goods are good.

Public Goods are credibly neutral by design and open; uncensorable.

The Public Goods stack for the onchain music ecosystem looks something like Indexing (cataloguing onchain events), Agreements (social / bnizz logic between events and entities), Context (offchain→onchain through data oracles, and front-end→onchain through data services).

We have a long way to go to make this a reality. But it’s our duty to do so, otherwise everything on the left of this diagram gets sucked into the silos of the right hand side.

Front-ends

Kinda self-explanatory, but front-ends are the experiences built on top of the onchain music ecosystem that drive engagement through interesting onchain-native experimentation.

Right now this centres around fairly basic streaming functionality. It’s likely that we will see an increase in social activity, especially apps building in the Lens ecosystem (e.g. keep an eye on beatsapp).

Where I think this really unlocks things is when front-ends get into the new digital rights / new markets paradigm that I’ve mentioned in previous blogs.

Also noteworthy, as explained in the assumptions at the start of this piece, the onchain music ecosystem isn’t limited only to “music NFTs”. It’s understandable that this is where front-ends have started their development, but I would expect that the pursuit of new digital rights and new markets will take teams to a different place over time. The music is of course important, but, music is bigger than the music…

Part of the initial rationale for setting up neume was to provide common infrastructure so that front-ends could focus on the experience level. As things progress I believe that this is key to everything, to be honest. All the words I’ve written above are redundant if we aren’t building fun, useful, and onchain-unique things that people can actually use.

I’ve referenced it a few times in this piece, but the Lens ecosystem is a shining example of the beneficial competition that can evolve on a common and open stack where utility is net positive rather than zero sum.

Looking Forwards

OK, this was a long one, to write and I expect, to read. Thanks for making it this far, I appreciate it. It felt important to spell out what was in my head in words.

Hopefully, I’ve made the case for seeing the onchain music ecosystem as something separate to, but also symbiotic with, the streaming ecosystem.

And hopefully, I’ve also made the case for why a Public Goods core is essential for the long-term prospects of the onchain ecosystem.

The natural call to action from this is to appeal for more thinking, building, and funding at the Public Goods level. To make this a reality we need to get better organised at building the narrative and coordinating resources toward it.

And also to start thinking bigger than just another streaming experience using Music NFTs. Music is bigger than the music.

Let me know what you think. This is after all just a sketch for now and will come to reality through the work of all of us, together.