Hi there! I would like some advice regarding some SOLID concepts. I would like to create a platform for musicians so they can publish their songs and be available for people who are not logged in. I was wondering if this is possible, to have a home page with public songs? Or only a logged user can see what is inside a POD? I hope you can guide me through this because finding basic examples regarding this topic it’s really tough for me at this point with my level of understanding. Any help pointing me to the right direction is more than welcome. Thanks in advance!
Yes, you can do that with Solid!
Files in PODs have permissions, and although by default those are private, applications can modify the permissions to make them public. There are currently two ways of telling permissions: WAC and ACP.
If you’re making a web application, I would suggest checking out solid-client because they have an API for setting these permissions regardless of the underlying mechanism.
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.
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
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
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
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: https://warm-inlet-30289.herokuapp.com/
Related: Deploy SOLID server to Heroku
The Client: https://solidwebapp-7a3cf.web.app
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!
I’ll keep in mind the
. for files and containers
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.
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.
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).
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.
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 https://timbl.com/timbl/Public/Test/Music/ . 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, podcastindex.org). 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: https://solidproject.solidcommunity.net/Verticals/Roadmap/index.ttl#this
Wonderful explanation, @NoelDeMartin ! 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.