I sadly don’t have the abilities to live out this idea — at least not alone. So everyone who finds this, is welcome to steal it or riff with me!

I’m currently trying to transfer from Spotify to Tidal. The main reason is that I want to use a service that pays artists better — and it’s a nice bonus that the sound quality is better. However, I prefer Spotify’s app and features. 1 And this inspired me to write out an idea I’ve been thinking about for a while.

Inspired by Mastodon, Apple’s MusicKit API, Podcasts and PeerTube

Third-party first

The official Mastodon client is perfectly fine — but nothing more. And I’d say the same thing (or less) about the Facebook app. But there’s a major difference: Third parties can make clients for Mastodon, using an open-source API. And not only can — the explicit plan is for the default client to be basic, and then let other people build around and on top of it. So where Facebook users are stuck in mediocrity, Mastodon users have tons of options, so everyone can find something that suits their preferences and budgets. 2

In addition to this, third-party clients push the whole platform forwards, with many great ideas. I’m not joking, when I’m saying that my top 5 social media apps are all Mastodon clients.

Here are some of my favourites:

Apple platforms:

Ice Cubes

Web clients:


Android clients I haven’t tried, but heard good stuff about:

Trunks (also web, I think)

A screenshot of the phanpy.social frontpage. It says «A minimalistic opinionated Mastodon web client», and shows two selling points: «Boost Carousel» and «Nested comments thread».

Phanpy is always trying out great stuff!

Like Apple, but not

Apple has a pretty cool API, called MusicKit. This allows developers to make third-party music players, while using the Apple Music library. Marvis is one example, and Soor is another.

But what if there was a similar, «complete» music library, that every developer could access for free, through an open-source API? And what if this library was run by a non-profit, who simply gave all the profits directly to the artists? 3

I love this blog post: «Wherever You Get Your Podcasts» Is a Radical Statement» Now, people (with Spotify in front) are trying to attack the open podcast ecosystem. But I wish music could be closer to RSS feeds. Just serving the files themselves shouldn’t be a big business!

Creek Music

OK, so allow me to explain my idea! The working title is Creek Music, as I Iike the idea of sending small streams of music around the world. 4 (And when I noticed that creekmusic.org was available, I had to grab it!)

OK, so let’s say we get access to the same 100 million songs that the big streaming services advertises. 5 This is gathered into a library, called The Source, which the Creek API 6 gives clients (apps) access to. These would be like the third-party Apple Music or Mastodon clients — but ideally, there wouldn’t have to be a first party/default client, so not sure if «third party» is the right term then.

But this is important: Users would subscribe for access to The Source directly — and not through the clients. This is to increase portability, and so that you can log into your library from anywhere. Perhaps you like one client on your phone, but another on your laptop? And if you’re in someone else’s web browser, you prefer a third? 7

That there are great free (and even open-source) Mastodon clients, like Ice Cubes, shows that there could be free client options here as well. But I would prefer it if every part of this stays ad and tracking-free — so I don’t think I would allow ad-supported clients. I would assume some of the best would be paid apps. But today’s streaming companies have both music rights and client development baked into their price — so the total cost shouldn’t need to be higher than what it is today. 8

What I think the API would need to serve

Access to songs

OK, so remember that I’m just dreaming here, and absolutely don’t know what I’m talking about… But PeerTube has this really cool tech, «powered by WebTorrent, that uses peer-to-peer technology to reduce load on individual servers when viewing videos.»!

Lower server costs = More profits for artists, and also less environmental impact. So that’s why I’d love it if something like this could be used when serving the songs themselves to clients.

Resonate (which I don’t think is doing too well), had some really cool ideas — including an interesting stream2own model, which is part of the inspiration for my payment idea. I’ll use myself as an example — and for simplicity, let’s assume $10/month of my payment goes to artists:

  • In March, I only listened to:
  • Fountains of Wayne would then get my entire $10.
  • Not only that, we would also register that Stacy’s Mom specifically has earned $6 from me, and All Kinds Of Time $4.

The idea behind the last point, is that I want listeners to eventually have heard a song enough times to then own them. If you’ve listened to an album to death (and then provided income for the artist), it doesn’t seem fair that you lose access to it if you stop your subscription.

Here’s a simple mockup I made, using Tidal as a template:

The songs have bars next to them that are filled to different lengths. Stacy’s Mom and All Kinds Of Time are all filled up.

Wohoo! I’ve listened to Stacy’s Mom and All Kinds Of Time enough so that I know own them! And the others are on the way. 9

  • Let’s say a song having earned $2 is enough to then own it. That would mean a user would «get» 5 songs every month on average, no matter how much they listened. This would remove the incentive to just stream 24/7 to get ownership.
    • In the backend, we could convert $1 to 1 million tokens. So a bar takes 2 million tokens to fill up, and at the end of the month, 10 million tokens gets distributed depending on what you listened to.
    • (It would be neat if it could fill up during the month as well — but I’m not sure how that would work…)
  • Users should be able to click on the bar to purchase the song. And if the bar is filled up halfway, it only costs $1, etc.
  • You could do the same to purchase an album — and I think there could be a way for artists to set their own prices.
  • We’d probably need some crazy algorithm to factor in song length etc. -but you get the idea!
  • However, if I in April only listen to Stacy’s Mom and The Shin’s A Comet Appears — do The Shins get all my $10, since I now own Stacy’s Mom? 🤔

So, if a user, through a client, requests to be served a song, we would check if they have access to it — either through the song being owned, or by having an active subscription.

We would also need some sort of offline component. (And it would also be neat if users could upload files somehow.)


The API should also have a spec for playlists so that they can be easily shared across different clients and so that it’s portable. It would be great if clients had algorithms to create them — but if you save them to your user, it gets written to your Creek account. This would make it so you automatically have all your playlists if you switch to or log into a different client. It would also make it possible to share playlists with users, regardless of which client they use. You should also be able to subscribe to playlists and have cooperative ones.


Artists can gather songs in collections — that can be albums, EPs or whatever. It’s just a list of songs, a name for that list, and its own artwork. If a song has several artworks connected to it, I’m thinking users can choose which they like if they have them in a playlist.

Interlude: Portal for everyone!

I play in a band called Klondike, and we’re six members. All our six personal users have access to the band’s page,10 and here we can upload songs, artwork, collections, etc. But we can also upload songs and set them as private (only accessible by the members of the band, users we’ve approved, or just one person). This can be useful to share demos, or otherwise upload sound files. 11

There should also be some sort of artist verification process…


I also want artists to be able to post updates to a microblog feed on their artists page. And I want this to use ActivityPub, so that people can follow the artist page from services like Mastodon or Micro.blog. I would rather not create another iTunes Ping — so it’s important that the content get sent out of Creek, while still showing within it.

We could make this more convenient, by allowing cross-posting from other services. 12

It would be convenient to be able to sell merch/vinyls within the app — but that does complicate things further. So, might be just as good to use the microblogging feature to link out to stores.

It’s critical that links to songs, playlists, collections, posts, users, artists, etc. are universal, across clients — so that I could share a song with the world, and know that everyone could open it in their clients.


There should also be some sort of API to (privately) track listening habits, so that clients can use this to create algorithms. But this info must be transferrable!


You should be able to have live sessions — either just you and your friends, or public on the web. As a host and admin, I’m thinking you can:

  • Create a link that let’s people join as listeners.
  • Create a link that let’s people join as co-hosts.
  • Choose if listeners can come with suggestions.

DJ component

There should be one…. 🤷🏻‍♂️

Here’s what I’m thinking about the costs:

  • The cost of hosting and serving the songs would get deducted from the artist’s payment.
  • If the songs earn less than their cost, the artist would need to pay for the songs to stay up.

I’m interested to hear about what people think about this model! This would do a whole lot of «cutting out the middle man», with the process of «getting a song on Spotify» being pretty complicated. However, it would put some risk on artists — but the costs to host some songs shouldn’t be that bad..? And I think removing the risk from the non-profit is pretty essential.

Some notes on what I would leave to the clients

I want others to create the Music Enjoying Apps, and simply compete on functions and user experience here. The app makers wouldn’t be able to lock you in with network effects 13 or that your «collection» is stuck within an app. 14

And since every service would pay artists well (and equally), being the best place to enjoy music, is the only incentive.

  • Who has the best apps for the devices you use?
    • «Best» differs from person to person. Some might want something simple and sleek, while others want maximum customisability and organisation tools.
    • The aforementioned app Marvis has some neat stuff, like smart playlists. I think that if the API provides the folders and the playlists themselves, the apps can be free to write to folders and playlists the way they please.
  • Who supports the wireless protocols you need?
  • Who has the best algorithms for creating playlists and finding new music?
  • Who has the best curated playlists?
  • Who has the best sharing tools and integrations with other services?

It would be a bit like today, where some use Spotify, some Apple Music and some Tidal, except:

  • they would be able to share links between each other,
  • playlists, purchases, habits, etc. would follow the user if you switch clients,
  • and artists would only need to upload their music, artwork and posts in one place 15,

A carmaker could also make a client for their infotainment system — and everyone would have their playlists automatically! Stereo, TV, and phone makers could also do the same, of course!

So, what do you think??

As you can see, this is just me spitballing, and dumping all my ideas onto «paper». I might be an «idea guy» and have some web and basic design skills — but I have no idea on how to actually make this thing! There’s guaranteed a thousand technical reasons why this won’t work, and a million reasons why it’s a bad idea in general.

I’d love to hear your thoughts on this — and I’m happy if someone steals this idea, and even happier if someone wants to build it with me. Hit me up on Mastodon!


  1. I might write why some other time. ↩︎

  2. I mean, there’s even clients for Apple II, DOS, palmOS, Amigaand Windows 95↩︎

  3. When I say «artists», I guess I really mean «rights holders». Because we all know everything doesn’t go to the artists themselves! ↩︎

  4. And the only results I could find with that name, was something that looks like a defunct music label ↩︎

  5. Theoretically we should be able to pay better, as all the profits go to the artists. ↩︎

  6. Which I obviously have no idea on how to build. ↩︎

  7. I wouldn’t mind a client allowing users to sign up through the app - as long as the direct Creek user gets created. Apple would hate this though, so I don’t know. ↩︎

  8. $12/month seems like the base line - so I could imagine a Creek subscription costing $10, and then $2 for a client. ↩︎

  9. But fuck Hayley’s waitress. Not the song, but the person in the song. ↩︎

  10. Reservoir ,is my working title for this. ↩︎

  11. Piracy issues..? ↩︎

  12. But this does create duplicates of posts - so another idea would just be to integrate a Mastodon user directly..? ↩︎

  13. «All my friends use Spotify, and I want to be able to share playlists with them!» ↩︎

  14. «I’ve made so many playlists on Apple Music, and all my purchased songs are there!» ↩︎

  15. You know, since I assume world domination. ✌🏻 ↩︎