mjourdan Yes, personally I could use some explanations from someone who knows the code about how many deduplication mechanisms Funkwhale currently has, and how they work (between libraries of a single user / of different user on the same pod / accross federation).
Currently we don't have any deduplication in place as far as I am aware.
mjourdan Interesting! Could you tell us more about the kind of subsets you are trying to organise?
For example when I work on my university papers I can't listen to music with text, so I basically have a radio which contains only instrumental music. Then again I do have some radio with all jazz and one with all german rap music, so I have one-button actions for different scenarios when I want to listen to music.
petitminion Yes we have channels for that 🙂 But technically channels are just public libraries that broadcast themselves automatically to all the network.
This is a major design flaw on the technical level and should be resolved by splitting those two things properly into different classes/domains.
mjourdan When asking at what level we should distinguish between different content types, my question wasn't clear at all. My question was which of the following hierarchy should we have?
I usually don't want to have them mixed up. There is time for music, there is time for podcasts and times for audio books. I don't want to launch some music and have a random part of an audio book mixed in. I also have different needs for queuing those different kinds of content, random and mixed playback of music makes sense, while audiobooks should be played in order.
I've read everything, but I might have missed some points. My take on the storage/sharing problem is the following, maybe too technical but probably this should be taken into account anyway.
So someone uploads a piece of audio. Funkwhale will create an Upload which basically adds some technical metadata and stores the actual audio file or at least a reference to it. I don't think we should change anything here. Funkwhale doesn't care if this is a song, a part of an audio book or an podcast episode. Its just naked data. This one is always private. Its also not playable and is never directly exposed.
In the next step right now a track is assigned. We should add differentiation here already, since it might be a podcast episode or a song. And we want to know this. You can imagine by just adding a paperclip to the actual upload with some additional data. Now this track, episode or chapter is again private, never linked to but can be played back (by requesting the information from the Upload actually).
Now those items can be parts of collections. As @mjourdan this should be pretty easy and available all around the UI. You can add whatever item to whatever collection, maybe differentiated by content type, reasons for this are listen above. Those collections can be shared or sharable (be federated).
To resolve the above concerns and considering those collections are actually pretty cheap in implementation but not in the UI, we can have something like a hidden, implicit collection. This basically allows us to click on a track, click "Share by URL". In the background Funkwhale will create a new collection, with a random ID but without a name. This collection will be shown nowhere, it will only lead to a hint on the track "This is shared by URL". This way you can share whatever you want with different groups without cluttering your interface with thousands of collections you need to manage. Its also pretty easy to implement, if we want to go the collection path anyways.
A quick note: If we go this path, we can actually have a clean migration from libraries to collections, since they share a common ground (The uploads) we wont touch. This can be used to built up the new thing allowing people to migrate slowly, as soon as they are ready. We can even hide the collections behind feature flags in the UI until we are confident they are stable.
I totally ignored channels here for the moment, but I think this breaks the scope anyway and should be another discussion anyways.