What's wrong with libraries, and a path to fix them

petitminion

Library

mjourdan I'm not sure what design you are referring to. Anyway, I doubt showing "Music" in the UI in the sidebar would keep the "library concept" free. Because we would still do have the idea of the-single-place-where-all-content-is-to-be-found (eventually aggregated from different sources).

I'm refering to the penpot design where there is three categories in the side bar : "music", "explore" and "podcats". In this case we would not use the library concept in the front. Could be less confusing if we keep it on the back.

Sharing

mjourdan in the collection system I describe, any given album could appear simultaneously in (let's say) Collection A which is private, Collection B which is federated, and Collection C which is shared by link, and Collection D which is also shared by link to someone else.

Yes I understand this, but doing so the access right of a track is based on the more flexible access right of the collection it's in. It means you could share tracks without wanting. But this is actually how it works now. If you add the same track in a public library it ill be reachable.

So we can choose to keep our system like this and just change the concept of library with the concept of collection and add new features to it (dynamically pass a track, album, artist from a collection to another). But I still wouldn't change all the back-end terminology.
And if we drop libraries for collections, i would keep some rules like : only one audio content type per collection allowed. Or create a specific tag for collections so we don't follow audio-content we don't want to.

My proposition was to use the library concept in a user management space to handle tracks rights. But this is yet another thing to do and I think we can go with your proposition.

mjourdan I would avoid this kind of exclusivity. All content uploaded would be private until explicitely shared by it's owner.

this is the point yes. Allow a clear management of right access. But personaly I would prefer to keep things has they are now.

Channels

mjourdan Anyway, I worry adding rss feeds to libraries and collections would make things even more confusing.

yes we should never do that !

mjourdan I wonder if making collections a third kind of channels would be a good idea?

channels are not meant for that. Collection could only be public...so better not haha

For me the confusion about channel come from the fact that there is podcast channels and music channels. And when you go to /subscriptions clicking on "channels" you got a mix of artist and podcast channels...Its confusing. Instead of "channels" in the ui, we should have "podcast" (like we have actually in the explore section) and the music channels should be seemlessly integrated into the music content.

petitminion

We had a vocal discussion with @mjourdan and we writed our conclusions in this pad : https://pad.funkwhale.audio/zs-SKbVgROapjv56lsWWtw?both

abstract :

Collection would be the new name for our current libraries
How we should call default collections intented for content management ?
should we keep radios ?
how to handle the upload process ?

gcrk

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.

petitminion

gcrk Currently we don't have any deduplication in place as far as I am aware.

I think means the duplication of the content when your reupload the same file.

gcrk This is a major design flaw on the technical level and should be resolved by splitting those two things properly into different classes/domains.

Channel class inherit from the Library class. I don't see the issue but maybe we should speak about this when we work on the technical aspect of this design.

gcrk 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

Yeah I totally agree on this method. In our report we create the concept of "default or special collection" that could also be used to implement the use case. Without having to create a new collection entry in the db. Also we could keep the "special" collection called "libraries" in the backend since they do what our libraries are meant to : right and share management.
But maybe this is too much technical and we should focus on the design first, agree on it, and then starting the different working groups ?

mjourdan

Deduplication

gcrk

Currently we don't have any deduplication in place as far as I am aware.
[...]
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.

Uploading a piece of audio to finally actually store only a reference to it is what I would call deduplication. Not sure there is nothing to change here, because I suspect this causes these annoying odd things. That is to say, not finding content where it is expected, and technical maintenance to "purge" the uploaded content. If I'm not mistaken, the upload process doesn't only add references to already uploaded files, it also removes them which breaks the libraries where the content was first added to.

User story

For example when I work on my university papers I can't listen to music with text

Thank you for sharing!

Sharing

This basically allows us to click on a track, click "Share by URL".

Yes, sharing by url should be allowed for playlists and albums too. Same for the embedded widget.

Channels

I totally ignored channels here for the moment, but I think this breaks the scope anyway and should be another discussion anyways.

I think so.

Playlists

Is there a reason to have both playlists and collections? What sets them apart? Don't they have the same feature set anyways? Wouldn't it be better to merge them into one thing?

They don't have the same goals, so I don't think their feature sets overlap much.

Playlists are simple list of tracks aimed to be played contiguously. They can take the form of .m3u files that most (if not all) software music player would handle.

Collections on the other hand are about sorting out your ever growing music library. They can be seen also as mimicking what happens when you share your discs with your friends: you would rather share a handful of discs rather than a single one. And amongst those discs, maybe there is even a couple of playlists you burned.

petitminion

maybe we could merge them anyway by making collections ordered
If we merge them the design will be easier : we still have a playlist menu in the collection, this menu contain all the tracks of the collection ordered by the date they where added but you can change the order in that menu..

Let's say we do this. Questions:

someone has several playlists and wants to share them all at once. Would we create playlists of playlists for that?
how to handle nested collections in the playlist menu? How deep would we go?
for people who have several playlists, would we turn them all into as many collections? Why?

gcrk

My comments on the current spec draft:

Collections would be a way to organise any kind of music item, includings single tracks, albums, whole artist discographys, or playlists. Adding an item to a collection would be as easy as adding it to a playlist: open the 3-dots menu, select “organise and share” in the popover, and (un)tick as many collection checkboxes as you would like.

Is there a reason to have both playlists and collections? What sets them apart? Don't they have the same feature set anyways? Wouldn't it be better to merge them into one thing?

I will proceed tomorrow, I am noticing I am too tired to understand the whole thing now 😃

petitminion

gcrk Is there a reason to have both playlists and collections? What sets them apart? Don't they have the same feature set anyways? Wouldn't it be better to merge them into one thing?

Playlists are ordered while collections are not 🙂 but maybe we could merge them anyway by making collections ordered
If we merge them the design will be easier : we still have a playlist menu in the collection, this menu contain all the tracks of the collection ordered by the date they where added but you can change the order in that menu.. We don't have to implement playlist federation or management, it will be included in the collection management yeeaaah
I think its a cool idea 🙂 (#lazyness_is_efficiency)

petitminion

mjourdan how to handle nested collections in the playlist menu? How deep would we go?

Yeah the main issue, I wouldn't create nested collection/playlist. I would only allow one playlist by collection.
If we want various playlist in one collection we should keep separated concepts

gcrk

Follow-up from Mastodon: @Sporiff created a new draft after we had a call about technical details and possibilities. Here it is: https://pad.funkwhale.audio/8Qvwu_jZRuGPMvgNvjIhAg?view

Questions from @petitminion

why not use the user page instead of creating a "user library" page ?
why create a "collections" pages when we have the "explore" page. I think a "collections" page will be confusing, while "explore" or "federated content" is more clear. The content should be presented has playlist, feeds etc and not only as a list of collections.

If we want a list of all accessibles collections we could create it but in a sub-menu of the explore section with a very clear name like "explore unknown collections"

Questions by @wvffle

How about the Favorites automatic collection?
Can a collection be added to another collection? That way the library might itself be implemented as a collection which may simplify things.
I assume that a playlist can also be added to a collection, right? What would be a difference between a playlist and a collection in terms of playback? Can user change the order of tracks in a collection? If so, wouldn't that make playlists obsolete?
Whether the default collection is Private content or Public content should be changable in the user settings in my opinion.
Wouldn't an ability to upload to a specific collection be simpler? Just go to the desired collection page, click the upload button and the uploaded content is automatically added to the said collection.

Answers by @Sporiff

I'm not sure that it's simpler to have favorites as a collection or in its current form. It may be better as a collection given that it would give us the option to include other types (albums/artists)
This would be a question for @georgkrause, but the library isn't really a container. The uploads can float freely without needing a container, so it's conceptually not that complex.
This depends on 2. From our discussions, a playlist is just a collection that is extended to include track positions
Possibly, but the safest assumption (and sanest default) is for the content to be private. This avoids any possibility of content being made public by mistake
This is something I would have in addition. For example, users can go to a specific collection and choose to upload music there. But the happy path should be that we don't introduce unnecessary steps for uploading content if the user doesn't want to create collections or just wants to add music to their library then sort it later.

gcrk

@wvffle How about the Favorites automatic collection?
@Sporiff I'm not sure that it's simpler to have favorites as a collection or in its current form. It may be better as a collection given that it would give us the option to include other types (albums/artists)

I don't agree. The current implementation of favorites is abstracted enough to favorite whatever you want, its just not in the API and this is called stable. So its a dilemma we can solve pretty easy with V2.

Also, favorites are a concept of activitypub which can be applied to everything, eg users. But users cannot be in a collection, so it doesn't make any sense to actually store the favorite as a collection.

If we want to have a automatically generated collection which contains all the favorites, we can add one, but for me the dynamic collections are technically different from static collections, since they are unable to manage access properly.

@wvffle Can a collection be added to another collection? That way the library might itself be implemented as a collection which may simplify things.
@Sporiff This would be a question for @georgkrause, but the library isn't really a container. The uploads can float freely without needing a container, so it's conceptually not that complex.

Well, library as a term for all playable tracks isn't really something which has an implementation, its more a concept.

@wvffle I assume that a playlist can also be added to a collection, right? What would be a difference between a playlist and a collection in terms of playback? Can user change the order of tracks in a collection? If so, wouldn't that make playlists obsolete?

I can't see why we would want to add collections to collections? What is this relation displaying? Can't you just create another collection next to the first, eg by "Duplicate this collection" which takes over all properties and content and you can easily remove tracks from it?

Playlists are not obsolete. Playlists to have a order. Also, playlists don't manage access to uploads and are therefore able to implement something like shared ownership.

@Sporiff This depends on 2. From our discussions, a playlist is just a collection that is extended to include track positions

We had this in the first place, thats right. But later on we noticed we need to have something which allows us to implement shared owner ship, so playlists would be a different concept.

Possibly, but the safest assumption (and sanest default) is for the content to be private. This avoids any possibility of content being made public by mistake

Agree. Convention over Configuration, and making public the default is a nogo.

gcrk

My review feedback for the draft:

I wouldn't reference the feature-set of libraries. This is nowhere written down in a proper way so its not really a detailed description. This spec will be around for a long time when libraries might be gone already, so we need to avoid the references.
A general question is if we want to only allow tracks to be part of a collection or also albums and artists. I'd say only tracks. You can still bulk-add and bulk-remove a whole album or artist discography. But adding artists is introducing undefined behavior. What happens if there is a new song of an artist, would it be added automatically? I don't think this would make sense.
In "New terminology" there is the passage a collection might contain "any kind of audio". I think we need to be clear here: It can only be content where the owner of the collection is the same as the owner of the underlying upload.
"The library can contain as many collections as the user wants to create". Nah. In the free version you can create 5 collections and Funkwhale premium has unlimited! Buy now!
Just a technical detail regarding the models: We would use a ManyToMany reference between Tracks and Collections, and do not store an array of Collections for each Track.
I think we need to be more specific about the API Endpoints in order to make clear whats going on and to avoid the library reference (see above)
For the removing of content from a collection: I think Matthieus idea was to provide an easy way to manage collection membership right from the object. I think this is as easy to implement as much easier for the user compared to the approach in the draft.
In the sharing flow, we need to specify that the collection which is created while sharing a set of tracks is a hidden one and wont be displayed as a order mechanism.

Sporiff

gcrk

Agreed. I'm removing these.
The way I see it, adding an album/artist/playlist to a collection only adds the tracks that are currently associated, so it's not the same as "following" the artist
I'll clarify
Let's come up with a pricing structure soon! 🤑 /s
Got it. I'll clarify
Okay, I'll clarify
I did mention this can be done in the library, but agreed it's not clear. I'll clarify
Got it. I'll make this clearer.

mjourdan

I thought I did post my review on Mattermost, unfortunately it seems it just vanished. So here it is again:

Why have playlists been removed from the object lists? What about interoperability and [questions raised earlier](https://forum.funkwhale.audio/d/214-whats-wrong-with-libraries-and-a-path-to-fix-them/17 if implementing playlists as collections?
Why have favourites been removed from built in collections?
Frontend: where does "add content to libraries […] using a search feature within the collection’s page" come from? if it is a reference to my mockups, the search-inside-collection doesn't aim to add anything, it aims to look for content only in the collection
Upload flow
4.1. Why would user have to choose between content types? Metadata must be filled in already before upload, so content type is technically already known, and if people have to make a choice it's rather between music they listen to and content they make, ie between library and channels
4.2. Where are the format and metadata requirements gone?
4.3. I suppose the flowchart has been removed so there is some balance between all the described flows?
The upload session idea needs some elaboration. keeping track of the upload date to help organise the library sounds great but having as many collections as uploads less so.
I don't get the difference between "user collections page" and "user library page"?
It seems penpot can export again, so I would rather link to gitlab-hosted pdf instead of penpot

Sporiff

mjourdan

We need to make a decision about the shape playlists take on the backend, but if it's a requirement we can add them in and just make it part of the discussion for playlist implementation later
This may just be a misunderstanding on my part. Was your intention that the favorites collection just be another collection that houses all favorited content, or that it should be the mechanism by which we sort favorites? For example: if I favorite a track, is that just a shortcut for sending it to the collection or does it favorite the track like we currently do and add it to a collection just for browsing?
That's my misunderstanding. I'll update.
For these:
4.1 This came from a discussion Georg and I had relating to uploading different categories of content. If I'm uploading tracks to put into channels, we might want to be able to suggest to users when they uploaded a content type but haven't put it anywhere. Picard doesn't label audio files with a type. This may be out of scope for this, so it's definitely something we can come back to later when we have a clearer idea how we want the channel upload to work.
4.2 I missed these. I'll add them
4.3 I'd like to add the flowchart in as a graph in the spec rather than linking out, I just haven't done it yet
Okay, I can clarify this. It's basically the same thing we have now (where we store the session date/time for the upload and everything you uploaded at that time is included).
As I mentioned to Pablo I need to update this section to more accurately reflect your mockups
Great. Let's add the links.

mjourdan

Sporiff

Thanks for the answers, things are much clearer to me!

sounds like more thinking is needed anyway so whichever sounds reasonable to me.
I'll reply below
that's my mockups that were misunderstandable then, so I made a slight update to them
…
4.1. I think we've known how we want the channel upload to work for two years and the logic is still valid
4.2. alright thanks
4.3. ok
Ok
I must confess I am not fully satisfied with my mockups showing a "library" tab being full of "collections"
done

Sporiff

@mjourdan @gcrk I've updated the linked draft in line with the discussion in this thread. Could you both take another look and let me know if everything looks correct?

In particular, I want to know what you think about the limitation around adding remote content to collections. When we discussed it we mulled over whether or not a user should be able to create collections using remote content, but ultimately decided against it for the reasons outlined in the spec. Matthieu's spec explicitly mentions adding remote content, so this may be a point of disagreement.

gcrk

Sporiff I basically see a basic problem with implementing additions of foreign content to my collections.

What if the owner of the foreign content stops sharing with me?
Since my collections are sharable, can I basically reshare content which is owned by third parties?

A workaround might be the following:

Collections can be private, shared and public.
If a Collection is public, I can "pull" its content into my Library (Technically this will create new entities of the audio which are owned by me).
This wont be available for shared entities, since they are not public.

This basically means, if a user sets its collection to public, everyone can acquire the contained content. When the collection is set to not public anymore, the content may or may not be already owned by others (But it could be downloaded and uploaded again anyways).

@mjourdan Does this sound like a fair deal to you?

mjourdan

Sporiff

In particular, I want to know what you think about the limitation around adding remote content to collections.

This question relates to this other one:

Was your intention that the favorites collection just be another collection that houses all favorited content, or that it should be the mechanism by which we sort favorites?

As of now, people can add any accessible track to their library, by adding them to their favorites. These are the only remote content that currently appear in the library, but it is enough to create confusion by mixing uploads and remote content in a user's library. As we only aim to make things easier to understand, no change of mechanism would be required I think.

On the other hand, adding albums, playlists and artists to favourites could benefit from such a change.

Matthieu's spec explicitly mentions adding remote content, so this may be a point of disagreement.

Oh no, I don't believe there is a disagreement. I don't think I talked about adding remote items to local collections for instance. What I did mention though was adding full remote collections to library. I think content we own (uploads) and content we follow should be kept in separate libraries, the only exception to this being favorites (and maybe playlists…).

I basically see a basic problem with implementing additions of foreign content to my collections.

If I am not mistaken, access to foreign content is an issue we already have with:

favourites (which is annoying because we're talking about pieces of music that matters the most to people)?
radios (https://dev.funkwhale.audio/funkwhale/funkwhale/-/issues/1717)
anywhere else while browsing remote content (example here)

What if the owner of the foreign content stops sharing with me?

Then the content would not be accessible anymore, and the collection would appear grayed out in the collections list. With something like a forget/unfollow button?

Since my collections are sharable, can I basically reshare content which is owned by third parties?

Nope, because that's not your collection, that's theirs.

A workaround might be the following:

If a Collection is public, I can "pull" its content into my Library (Technically this will create new entities of the audio which are owned by me).

This wont be available for shared entities, since they are not public.

I'm not sure I understand this two points.

You mean to add a remote collection to your library you can or you must pull its content?
The owner of the new entity would still be able to set the visibility they want, right?

@mjourdan Does this sound like a fair deal to you?

Content replication is the kind of things I considered too. It has downsides, like quite a radical change of philosophy in how access rights are managed, encouraging unreasonable duplication of content, and requiring people to choose between uploading or adding remote collections to their libraries. This sounds like too much tradeoff over what is currently done. Also, Funkwhale claims to be a social thing. I feel like considering that when Funkwhale users leave or whole instances shut down, it's fair to see the conten they used to share go away too.

Sporiff

gcrk This approach would answer the open question. "Add to library" would be the much more descriptive term for this.

petitminion

I don't understand why a user could not add remote content to one of his collections ? I don't see any problems about this. I even think it would make the exploration experience much better to allow this. Because if we don't how should I organize the content I follow ? We should create another kind of collections ?

gcrk What if the owner of the foreign content stops sharing with me?

the content is grey out and set has unplayable (if there is not another source available)

gcrk Since my collections are sharable, can I basically reshare content which is owned by third parties?

It depends. A own the content, B follow A, C wants to follow B. The question is : does C have the right to access A content ? This is something that A choose. B can only power up discovery of the content, but the actual audio file rights are always managed by the uploader A.
Another way to see it : "add to my collection" doesn't mean "buy this content", or "own this content".

Another other way to see it : Rights are attributed to a track, track to an upload, upload to an audio file.
You can have various people uploading the same track with various right access. The more flexible right will prevail.
The uploader of the file is legally responsible (because he is the one who uploaded the audio content). If a user add a foreign track to his collection that is public, he is not copying the audio file. he is just saying "I want to have access to this file and add the metadata to my collection". No need to copy the audio file.

gcrk

mjourdan 4.1. I think we've known how we want the channel upload to work for two years and the logic is still valid

To get a bit more into detail here: The idea was you can just upload content, without making any decision. You just throw it into the pool of your files. Then, you could already share it by link before you either put it into you collections, add it to a public collection or publish it on your channel.

At the same time, uploading stuff to a channel can be implemented. And I fully agree, the current UI isn't really user friendly and needs an overhaul.

I guess most of our disagreements are based on the fact I am always looking on the technical perspective while you have the user interface in mind. Thats probably a good chance for us to get to a pretty good solution after all 🙂

« Previous Page Next Page »