Music Platform

One thing to keep in mind is that whilst solid can do this, given you can store any type of content, it may not be the best/most performant experience, unless you front the music files with a CDN somehow — also, you’ll likely want to factor in that musicians usually want to be paid for their music.

Great support, thanks for the information and your quick reply, @NoelDeMartin ! I’ll try to create a prototype and share the code here in this thread so it can be discussed in detail in the future, let’s see if I manage it… I saw a similar topic (Music platform and help with understanding Solid a bit more) but unfortunately there wasn’t a clear reference to a code that can guide someone or introduce it into the subject.

1 Like

Thanks for your input @ThisIsMissEm. I see your point and it’s really important what you say, because I would like to create an app where in the end it should not be different if sharing audio, video or pictures in terms of the client-server communication and main architecture. You can think of the classic web app where there’s a home page with public project/creations, etc and a detail view with more info when clicking on the items, i.e. Bandcamp. You could be showing audio samples, photos or videos and the files should be hosted in the same way and therefore consumed, but using SOLID principles. I’m not sure if I expressed myself correctly :slight_smile:

Probably your main challenge in that traditional web app sense is going to be “how does my app now where to fetch data from to display the homepage?”, i.e., it’d need to keep track of the WebIDs that are it’s members, which makes it inherently stateful, vs something more stateless where it’s just interacting on an individual user basis.

That’s it! But on the other hand, I’ve run and seen how “mashlib” woks (GitHub - SolidOS/mashlib: Solid-compatible data mashup library and Data Browser) and it looks quite similar to what I want to achieve, except files can’t be uploaded from the web interface, but for the rest it’s kind of the same philosophy. If you publicly host a “mashlib” server instance, anyone would see the content store (folders, etc). Isn’t it?

Right, so I might be wrong here, but my understanding of mashlib is that it’s only ever showing a single users data at a time, that is, you’re just browsing a single WebID / Pod, and maybe following some relationships to pull in additional public data.

This typically works by having the URL be the WebID, or by passing in the WebID via the URL query params or similar. Compare that to a homepage with multiple users data all served together from the root, i.e., /. In the homepage you’ll need some store of data which is “which users am I loading data from”, which then gets into some tricky territory when it comes to sorting, paginating & making the loading performant (these might be able to be patched over by using QPF or Sparql query indexing)

But you’ll still need something that acts as a central store for your “homepage”, and some way to “find” the content you wish to display

1 Like

I get your point regarding the central store, thanks again for your answer! And for the “mashlib” I don’t know either but it looks like the folders are publicly accessible in the way I run the server in my local machine (without been logged in or authenticated), at least by following these steps: GitHub - CommunitySolidServer/Recipes: Example configurations for the Community Solid Server

Hi there!

Thanks again for your advices @NoelDeMartin and @ThisIsMissEm ! I think I managed to create a prototype of a client displaying content (audio) from the server in a public way, it means, without being logged in, using a Home page that leads to a Detail page.

I don’t know if any of you or people in the forum will have a look at it and propose some changes in order to improve a better usage of the solid-client library. The actual code is quick and dirty and I’m not very happy in the way the data is consumed as Linked Data, there should be better ways to wrap the objects and so.

The Server:

Related: Deploy SOLID server to Heroku

The Client:

Screenshot 2022-12-01 at 17.56.05


The Repo: GitHub - fan-droide/solidclientwebapp: An example of SOLID client Web App to access Community Server resources

Any input is more than welcome!

I’ve had a look at it, and it seems fine regarding working with the Thing API — it is quite a verbose API to work with.

We do have a method for getting a list of all the resources in a container dataset, which is getContainedResourceUrlAll which may be helpful for you.

Do also keep in mind that containers or files starting with . are not explicitly private or hidden, like on a unix file system. Only the permissions system really controls what a user can and cannot see, whether that’s WAC or ACP.

Thanks for the hint! I tried getContainedResourceUrlAll and worked like a charm! :slight_smile:

I’ll keep in mind the . for files and containers :wink:

Nice, it works so I think you already have the basics right :).

What I’d look into to make this more Solid-like, is how does people choose who’s music to listen and how do musicians upload files to their PODs. Ideally, if I’m a musician and I already have public music in my POD, this should be able to work automatically without me even knowing that your app exists.

This can be achieved for example using type indexes with things like schema:MusicRecording and schema:MusicAlbum.

Thanks again for your response and support, @NoelDeMartin. Here I have drawn a quick diagram to try to put my ideas in order. I’ll copy the text from the picture below for better feedback.

  1. At the Home Page you can see folders (albums) and songs at root level. The elements at this view can combine actual POD’s root content and a history of recently played tracks for example. If applying the same philosophy you can think about albums and photos (not strictly tied to music).

  2. In the end, what this app would do is to access files collections that are publicly available in users’ PODs and filter the content and apply a UI so it’s meant to work specifically with audio, images, etc. For that schema:MusicRecording and schema:MusicAlbum will definitely work when uploading files or retrieving them.

  3. What I’m not sure at this point is how the search engine would work, i.e. to query information from different sources and also if you login to the app with POD2 and the app is by default using POD1, how the information can be merged, but this should be possible as far as I’ve understood.

Yes it sounds as though you want to make something quite like the mashlib media pane but more sophisticated. See a demo bit of music at . Note it plays a song then the next and so on. By the way you can upload music to the folder --just drag a file from your desktop onto the green “+”. You need write permission, so you can’t add to my test data. (I have a whole bunch of music elsewhere on my pod - I just linked my iTunes media folder and I can listen to it anywhere but its not public).

Yes, I think that’s exactly the point!
I tried to register in that server but it throws an error, I guess it’s due to permission, maybe…

By the way, @timbl thanks for discovering me the trick of drag&drop on the green plus, I wasn’t aware of it

Thanks for the wireframes :).

Overall I think you’ve got the right idea, but maybe you’re missing something when it comes to the information architecture: Where’s the data? Which is understandable, this is what makes Solid different from other technologies after all.

There are different ways to go about it, let me share some ideas.

A “Pure” Solid Application runs entirely in the browser and has no server-side component, that’s what makes it completely decentralized (this is my own definition, there’s nothing in Solid forcing you to do this). So the application itself has no data, and the first thing a user should do upon visiting the app is introduce where they want to get the data. For example, adding their favourite artist’s WebId, or if they are an artist logging in to manage their media collection.

But of course, most users don’t know where to get started, so it’s a good idea to provide something. But I think it’s important that this “something” is opt-in, your app should still work without this. Again, this is just my opinion, you can do a Solid app with a hard server-side dependency if you want.

In your case, the trouble is where to get this information. I have done a couple of apps and I’ve been lucky enough to find public information available (for movies I’m using TMDB, and for recipes I’m using the web itself). But what you need is a database of artists’ Solid WebIds, which you are not going to find. So your app/service will probably need to become this database, at least for now.

One similar use-case that comes to mind are podcast applications. If you ever use one of those, you’ll see that you can search for podcasts, which is weird because podcasting works using RSS that is a decentralized protocol. That’s because they’re using a public database (for example, But you can still add feeds on your own that aren’t listed anywhere. I think that’s the same idea, your app can provide a service to find artists’ music, but it should work even with Solid PODs that aren’t listed in that database. Even better, this database of artists should be decoupled from your app so that other people can build their apps that are compatible with yours.

So, to summarize, your app needs to connect with:

  • A backend service giving access to a database of artists. This can be your app itself, but it can also be decoupled as an external API. Furthermore, it could be a Solid POD with public indexes listing artists’ WebIds. But this will probably complicate things, personally I wouldn’t recommend starting with this (although it’d me mighty cool).
  • A user POD (optional), this is just needed if the user wants to upload their own music or save favourites, create playlists, etc.

I hope that’s helpful, and let us know how it goes :).


Note this application area is part of the “Media” vertical in the Solid Verticals roadmap:

1 Like

Wonderful explanation, @NoelDeMartin ! :clap: I think it’s much more clear for me and anyone who wants to do something similar or to understand the SOLID’s approach. Big thank you! I’ll keep you posted if I make any progress!


Isn’t the public data to use here MusicBrainz for that huge mass of already published music? So just as in Media Kraken I type and it pulls in and auto-completes from IMDB, so here I type an artists and I can search existing published artists (and albums and tracks) there in a music app using MusicBrainz.

And then I can build a local index of all the tracks I have from local artists by pulling it out of the MP3 metadata directly.

1 Like

I think this would be useful to make a Music Tracker (maybe something like, but if the intention is that artists upload mp3 to their own PODs, this probably won’t solve the problem. It could be useful to populate metadata easily though (but I think most metadata will already be available in the mp3 file).

As far as I understood, the idea is that artists upload their mp3 files so that other people can listen to them without downloading anything. Something similar to Spotify, for example. If people have to bring their own mp3, the UX won’t be great. And to be honest, I’m not sure how many people would be interested in using this rather than just playing the files locally. Although I guess it could be interesting to explore, but I think it’s a different idea.

In any case, this type of project is very likely to run into a chicken-and-egg marketplace problem, so maybe having something like that would make it more useful at first (but for a much smaller number of people).

By the way, I just remembered there is a similar project built with ActivityPub, so maybe it’s worth learning how they do it. It’s called Funkwhale. Interestingly, they also call their servers “pods” :sweat_smile:.

1 Like

Thank you so much again for your replies and feedback @NoelDeMartin and @timbl !! :slight_smile:

1- Using MusicBrainz as a starting point to retrieve public data would be a great idea. MusicBrainz provides JSON-LD format with their API, so the Linked Data objective wouldn´t be missed for a SOLID approach as @NoelDeMartin mentioned Music Platform - #17 by NoelDeMartin

" […] it could be a Solid POD with public indexes listing artists’ WebIds"

It’s also beneficial to engage new comers to select their favourite artists and from there build their music taste. On the other hand, I don’t see this idea really compatible with a public repository of songs, as in @timbl ( I don´t know to what extent the public hosting of copyrighted music can derive into legal consequences. I don’t want to greet a bunch of lawyers at my doorstep after my first commit :sweat_smile:

2- I agree with @NoelDeMartin in “the intention is that artists upload mp3 to their own PODs” and make them available to anyone (logged in or not), or just the audience they want to target . Thanks for sharing Funkwhale , I´ll definitely dive into it!.

3- With regard to the market I have my concerns and this also connects to a previous comment from @ThisIsMissEm Music Platform - #3 by ThisIsMissEm “musicians usually want to be paid for their music”. Well, sorry for the off-topic and making it personal, but when I started thinking of this platform, some time ago, the challenge was not exactly the business, it was the technology though. I wanted for music the same principles I like from software, openness and collaboration. A concept like SOLID is what I expect (as a geek) from a tech company focused on independent music (i.e. Jamendo). I can give you more details about future plans on how and why it could be worth it, but it would be out of the scope of the really exciting part which is actually building it!

PS. I think Projektor can be a good example also and starting point except for the public willingness