neume, a public retro
It's important to talk about what we've learned when we build things
Today, I want to take a second to talk about neume and conduct a public-facing retro.
Goals of neume
neume is somewhat a continuation of a lot of what I learned while working at PRS and ICE Services. And in some ways what we were thinking about at JAAK, way back in 2015-19.
The need for an open and available database for the future music industry has never been far away from much of what I’ve worked on over the past few years. We do not have a Global Repertoire Database, and likely never will. We lack incentives and business rationale.
Backstory
Using the meme of blockchains being machines for finding consensus where it can’t otherwise exist, at JAAK, we developed the idea for KORD, “tooling for building large scale, decentralised databases describing real world entities, where individual participants are both economically incentivised to provide useful, efficient services and are held accountable for any wrong doing”.
However, we were early, and probably wrong about a lot of what is actually needed. Unironically, with the hype around RWAs at the moment, maybe there will be similar efforts by others in the near future.
Music NFTs
Anyway, 2021 came around and all of a sudden artists were selling music NFTs to collectors. Units were shipping around ideas of patronage and some intangible sense that music suddenly had value again. But time and time again the question of utility raised its head: what are these things and how can they be used?
Some aggregators were built that allowed for streaming of music NFTs, a fairly simple use case analogous to the blog eras. And the market concentrated on a small number of music NFT marketplaces that look like soundcloud or bandcamp.
All the while, music NFTs themselves remained extremely simple in function, which is a good thing. The complexities of fractional ownership and different elements of copyright were essentially abstracted away. Something that we didn’t really foresee at JAAK, though seems obvious now.
Sellers and buyers may not have been aware (and may not still be), but the simple act of packaging the entire transaction into a simple mint/sell/buy works because there is inherent legal threat; as soon as the market gets to a certain size then it has been built on a world that the traditional industry already owns and actors are largely doxxed. It is meat and potatoes for the legal cases to start up, once the business case is there for them to do so.
Building in front of the inevitable future
More concerning for me though is that despite the promise of a new composable ecosystem of activity and data, teams building in this meta have still been incentivised to build platform businesses: focus on platform UX, populate internal closed databases, and compete on in platform activity.
neume is an attempt to get ahead of the inevitable access-to-database moat that comes from that thrust of development. Providing an open-source alternative that would allow anyone to spin up a front end on top of music NFTs and compete on the utility that they can provide.
Where we’ve got to
A significant amount of our early development at neume was focussed on building out a robust and extensible ETL indexing solution. We drove this by writing code for the leading music NFT marketplaces, and hoped that it would be picked up by developers for whatever additional marketplaces they wanted to include. In that, it would provide positive-sum developers where the more people using it would make it more valuable for everyone else.
The theory at the core of neume is based on Snapshot’s strategies. There is a protocol on how to write a strategy to look at a contract that defined a set of NFTs. This is collated into the crawler that then runs and pulls out all the relevant information.
To date, the key marketplaces we have done this for are Sound.xyz, Catalog and Lens, with Mint Songs and Zora v1 being included along the way.
We have built a pretty solid indexer and crawler and have been considering approaches to make the data generated in neume more available through writing to Arweave and building SDK integration. And the more ambitious goal of establishing the “network” side of neume network, whereby multiple nodes can work together to lessen individual crawling work, and ideally define subsets of the data that they themselves wish to crawl.
The grand vision, in my eyes at least, for a project like neume is to provide the foundation for an open stack to support the potential onchain music industry, which sits in parallel to the traditional music industry. Read the linked blog for more in-depth thoughts on what that means.
Along the way we have managed to successfully develop neume from an incubated project via HIFI Labs, into one that stands on its own two feet, as I discussed was the plan in the blog “taking neume towards escape velocity” in March earlier this year.
The challenges
Stalled market / lack of interest in development
Fundamentally, development in music NFTs has stalled. What once represented a relatively open design space has concentrated towards becoming a proxy for selling downloads.
For clarity, there’s nothing wrong with that. There is a place for bandcamp in music, as there was for itunes, as there probably is for web3 download store. But, it probably doesn’t require decentralised infrastructure to support, and we could be building so much more.
Unfortunately, the progression towards building platform businesses led to the inevitable incentives once the bear market hit. Scale and reach became dominant over unit sale price, and a lowering of overall value attainable through selling an NFT drove platforms to move to transaction-based take rates over gain-share mechanics.
The rise of free or nearly free NFT mints broke the relationship between artists and platforms of sharing success. Platforms are now incentived towards the number of mints rather than how much money they raise. To quote Sound.xys’s FAQs, “A flat mint fee makes us ambivalent to the popularity of an artist”.
The result of the last couple of years of development has been a focus on price optimisation rather than experimentation. And, honestly, that’s just boring to index or build experiences around.
Building for developers / composability doubts
Now, all of this is of course fine, markets cycle up and down. But the real kicker with regards to neume, is that we have committed the cardinal sin of a sole win-con around developer activity. Did I learn nothing from JAAK?!
Take this as a learning, everyone, please, if the success of your startup is reliant on other developers using it, then, you face an extremely difficult road ahead. Build something consumer-facing.
Of course, I knew this, but hoped that the open-source framing of neume would lead to a different result. But nah, there is an extremely small potential market when your project is aimed towards the community of developers. Especially when that is a niche (web3) within a niche (music).
Furthermore, a core tenet of neume is that the future internet will be more composable than the current one. Thin applications etc.. However, I now believe that this has been somewhat unproven to date, and that it is a weak assumption to build upon.
It may ultimately prove true, but far more likely in my opinion, where a platform can build a platform business it will do, and will seek moats where possible. And that goes against composability.
Generalised index solutions good enough / niche music needs not relevant
The common response when discussing neume with someone usually goes something along the lines of, why build it when generalised indexing solutions exist.
My counter is that music is different, has very specific needs, and if we don’t build an indexing solution with these in mind then music & crypto will never be successful as a standalone industry.
I still believe this.
But I also think that there’s an argument to be made that there’s some over-cooking at play, again. Just as we went down the rabbit hole with JAAK, trying to build a decentralised rights network that could deal with all the complexity that music rights have, with neume, maybe, actually, a generalised indexer is just fine for what music & crypto needs now and in the foreseeable future.
Take, for example, the second layer of the stack in my onchain music industry essay, the “agreements network which sits on top of neume and other indexers. The intellectual challenge of such a protocol is fascinating (it is likely something similar to KORD)… but is it needed? If it is needed then is it actually more generalised than something specific to music? And if it needs music niche specifications then does it need to be open and accessible?
I would argue that to be a better place than we were before then, yes, but is there strong enough business incentive alignment?
What now
We probably need to set a new direction for neume. Or establish an iteration on its current direction.
neume started out as an open-source project supported by HIFI Labs. When focus at HIFI shifted, we brought neume out of incubation, and sought grant money to continue development.
Lens Protocol has been very supportive through this process, providing a small grant to focus on Lens NFTs. We have also been provided some grant funding via Gitcoin, from supporters and match funding.
At the time of writing we have about $2.5k in funding in our treasury (basically the Gitcoin round).
There’s an argument to take that sum and put it towards the final part of development that we have discussed as a group (Arweave & SDK development). Or maybe to use that to seed a revised focus.
If you have any thoughts then don’t hesitate to drop into our github discussion area, all our conversations are open and public.
I personally have been mentally invested in neume since conception, well over 18 months ago now, which I have done pretty much gratis (outside of being paid to work for HIFI Labs). Honestly, I need a bit of a mental break so that I can focus more on JUICE, F2P Music, and Interstellar (where I am now Head of Copyright). And so will probably become more of a passive community member for a little bit.
That said, I do think there is a thread that ties all of this together somewhere, I’m just not sure yet… hit me up if you can see it where I can’t!
neume is of course fully open source, all the code is in our github and available to anyone who wants to take a look and play with it.