@funkwhale/development I have a question about right management. Actually a tracks privacy setting is manage by the library. How would this work for collection ? Has I understand the spec, the build-in collections will be the one managing the privacy settings of the tracks. If a user want to add a private track to a public collection we should prompt a warning explaining that this tracks will now be available to everybody, and that it will be automaically removed from the buildin private collection.
If we agree on this we need to add this in the spec (lacks backend enpoints and ui design)
@petitminion If the collection or library manages the visibility, there is no such thing as a "private track". You can upload a track, its private by default. If you assign it to a public collection, it will be visible.
@petitminion@georgkrause As I described it in !2638, the privacy setting should essentially be a check to see "does the requesting user have access to this track in any collection?".
If I upload a track and add it to a private collection, then share it with 5 people, only myself and those 5 people should be able to see it.
If I add the same track to a public collection, anyone will be able to see it, because everyone has access to that collection. It stays in both collections, because I use the collections to structure my library, but if someone encounters the track in e.g. a playlist they will be able to see it because they have access to the public collection.
I do think a warning of some kind might be good for public collections given how permissive they are, but this should probably only be a one-time warning (otherwise it would get pretty annoying). Maybe @mjourdan has some ideas how we could represent that.
I do think a warning of some kind might be good for public collections given how permissive they are, but this should probably only be a one-time warning (otherwise it would get pretty annoying). Maybe @mjourdan has some ideas how we could represent that.
What about showing up a toast when the files visibility changes?
this popup is great and it's a good idea to be able to reverse the change o/
If I upload a track and add it to a private collection, then share it with 5 people, only myself and those 5 people should be able to see it.
@Sporiff how a collection is shared with user is not precisely defined in the spec. has I understand https://docs.funkwhale.audio/develop/specs/collections/index.html#sharing-mechanism the collection should have a list of user that can access the content of the collection. The attribute could be called shared_recipients. So we would have the visibility attribute and shared_recipients.
When sharing object an implicit/invisible collection would be create with the list of users in shared_recipients and visibility set to private. If there is "invisible collections" we need to add another attribute to the collection to know if it's visible or not...so in the end we would have three attributes: shared_recipients, content visibility, collection visibility. For me this is very confusing.
Instead why not implement shared_recipients and visibility for uploads directly ? This would allow to have a more flexible system : if we want to share objects we just add the users to the shared_recipients of the related Uploads. No need for invisible/implicit collection. No confusion between backend collection and frontend collection. Makes things more easy from my pov.
Also consider this case : An user create a private collection "Rock" to curate his content, then he want to make this collection public. He will have to make all tracks on this collection public or he will not be able to share this collection. This can be resolved by the playlist feature I proposed here #2275 (comment 62161) and that use the idea of shared_recipients being attached to Upload and not to collections
A public playlist can contain private content (it will not be displayed to user that do not have access rights)
A playlist is sorted.
Collections access right determine the collection's content access right.
Collections could contain various content type. Like playlists.
Concerns
Has noted in #2275 (comment 61335) the rights are managed anyway by the build-in collections, the other collections do not really manage right access to the content, which make them pretty similar to playlist.
Since we spoke about adding playlist to the collections, it means they could have various content types. Which is confusing for me.
Has you see in the current approach collection are an hybrid concept that mix content right management with content curation. It also mix contents types.
Proposition :
Use the build-ins collection has a right management system. This means there will only have build-in collections. User couldn't create customs collections.
Curate the content in playlists. If a private track is added to a public playlist, it doesn't matter.
Playlist can only contain music content type. But we could add full albums or artist in playlist and navigate through them in a non-sorted way (keeping the sorted aspect of the playlist ofc)
Sharing would be done exclusively trough playlists (to keep thing simple) and user activities (see user follow feature)
Well actually i'm just proposing to stick to the basics : a right management system and playlists. In any case having a design of the collection page could help the discussion.
Since we spoke about adding playlist to the collections, it means they could have various content types. Which is confusing for me.
As far as I remember we decided against. I don't see why this would be useful, do you?
Use the build-ins collection has a right management system. This means there will only have build-in collections. User couldn't create customs collections.
But I want to share different parts of my music library with different people, this wouldn't be possible.
As far as I remember we decided against. I don't see why this would be useful, do you?
I don't think it's usefull, I wouldn't allow this. But in the spec it's suggested that we can add playlist to collections.
But I want to share different parts of my music library with different people, this wouldn't be possible.
It would why not ? This differents part would be playlists. Which is the same thing has collection has far has I understand.
Another point is : if we have only one way to share curated content (and not two way has it's proposed here) we could implement some new features around it more easily.
Like tagged base playlist/collection, where an user can tag its files or track with various tag, and them automatically add them into the appropriate collections/playlists. This would be a flexible system, and pretty simple one
Since we will allow to follow playlist, I think it's confusing : should I follow playlist or collections, what is the différence ? How I'm suppose to remember if I curate the content on a playlist or on a collection ?
It would why not ? This differents part would be playlists. Which is
the same thing has collection has far has I understand.
@petitminion The primary difference in my opinion is that a playlist
is ordered, a collection is unordered. A playlist is a specific way
to listen to a group of tracks, while a collection is a way to
organize content.
yes but this is the only difference and it can be easily erased. If you shuffle your playlist, it becomes a collection. I wouldn't build two big feature like collection and playlist just for this reason (lots of code duplication, lots of documentations, confusions)
Also I have the intuition that there isn't a lot of people using the sorted dimension of playist, most people use playlist has tags. But indeed we should have sorted playlist in funkwhale which can be done. We would just allow a way to browser this playlist in a non-sorted way. Allowing to see artist or album of the playlist.
yes but this is the only difference and it can be easily erased. If
you shuffle your playlist, it becomes a collection. I wouldn't build
two big feature like collection and playlist just for this reason
(lots of code duplication, lots of documentations, confusions)
@petitminion The idea with collections is that sharing can be
facilitated in many ways. I think of it mostly in terms of the
following:
I create a "Rock" collection with my favorite rock tracks
I share this collection with my friend Pablo
Me and Pablo can listen to all items in the collection
This would work just fine with playlists as well. However, I think there
are many other situations we need to consider, for example the sharing
of a single track. This is one of those things people often want to do,
but in Funkwhale's world it's not currently possible because of how
libraries work. The workflow should be:
I select a track in the Funkwhale interface and click "share"
I choose who to share the track with
Funkwhale implicitly creates a collection for just this track, and
grants the user(s) access to the collection
This wouldn't really work with playlists, or at least it would be the
wrong nomenclature. People think of sharing playlists as being a
specific action, but the idea of needing to add something to a playlist
just to share it with their friends seems somewhat counterintuitive.
It's way easier to wrap my head around 'I don't have permission to
listen to this specific song from this playlist/collection' than it is
to wrap my head around 'I have a song that I want to share with my
friends and I should share it in a playlist rather than a collection
because only these types of lists are public'.
Also I have the intuition that there isn't a lot of people using the
sorted dimension of playist, most people use playlist has tags.
Definitely, some people are currently using playlists as collections
because we don't offer collections. They are using them to group content
together and share with friends, but not to actually structure
playlists. However, if we offer both I think that people do actually
want to use both.
But indeed we should have sorted playlist in funkwhale which can be
done. We would just allow a way to browser this playlist in a non-
sorted way. Allowing to see artist or album of the playlist.
This goes back to the idea we had previously, which was that "playlists
are collections, with ordering". I seem to remember we decided against
this (though I don't remember why, @georgkrause might).
Mostly because I don't want to implement to mechanics that control access.
Collections determine who can listen to a track. period. Playlists are a way to create a curated list of tracks to listen to. Its no access control, its just a list of pointers.
So why not forbid to add private tracks to public playlist, and only have build-in collection has a right management system, playlists to share curate content, user follow to share collections activities ?
not forbid to add private tracks to public playlist
Because it would stop people from setting tracks to non-public again after it was public, which is a no-go.
A uploads a song, sets it to public
B adds the song to a playlist
A wants to make the song non-public
only have build-in collection has a right management system
Again, because I want to decide which track I want to share with whom and this requires that the tools allows me to create multiple collections where I can decide who has access to it.
Because it would stop people from setting tracks to non-public again after it was public, which is a no-go.
A uploads a song, sets it to public B adds the song to a playlist A wants to make the song non-public
In this case the user is sharing content he doesn't own, if the track is set to private after added to a public playlist, we have nothing to do. The metadata of the track will still be on the playlist but the content will not be accessible. So we come back to the need of having playlist that allows different content visibility....
Again, because I want to decide which track I want to share with whom and this requires that the tools allows me to create multiple collections where I can decide who has access to it.
Okey but if this is what collection are, then we should spec them this way. Because for now we only have three privacy setting : public, pod, me. So we will only have three possibles collections anyway. If we want to allow a more flexible system we need to define how it will work. Which we didn't.
For me it doesn't make sense to have collection has a management right mechanisms (that some time is invisible, and sometime is visible has describe in the spec for the sharing links) and has a sharing system. Also it make no sense that a track can be in a private collection and in a public collection. This mix collection visibility and track visibility. We should have differents concepts for this.
I propose to call visibility an individual Upload attribute that have three states :
-public
-local
-private
On top of the visibility Upload should have a shared_recipients attribute, a list of user that can access the content.
This visibility can be set using three built-in Visibility collection. It is the only way to change the visibility of a track.
But to allow flexibility we can add people to the shared_recipients. This is done through two mechanisms :
A sharing link for individual object (track, album, artist)
The person opening the link will be added to shared_recipients. Since this attribute is independent from the visibility attribute, the content visibility do not matters
To curate his content, users can use playlists.
Playlist can contain any kind of content visibility. But some content will not be accessible for peoples that do not have the rights.
Playlist visibility do not affect content visibility
To allow user to share all the playlist content to a limited amount of persons, the user can share the playlist to group of persons. By doing so they will be added to the shared_recipients of each upload contained in the playlist, with an attribute allowing the process to be reversed.
In the case they want to make all playlist tracks public, a tool will allow to move the playlist tracks from the build-in private collection, to the build-in public Visibility collection. This ways it's clear that these tracks are now public.
A future features could allow the Playlist to be edited collectively. The content of the playlist will still follow the same rules (visibility is only defined in the visibility collection) but each user will have an option to share the content they added to the playlist with the other playlist owners (through shared_recipients)
We are mixing the flexibility of content curation with the flexibility of sharing. It's confusing for us and I can't imagine how confusing it will be for the end user. Let's keep things as simple as possible : collection are for management rights. Playlist are for content curation and sharing.
Playlist are interoperable objects that can be used in other software (imported/exported/shared) and can be followed. Collection are not
@petitminion I think we need to clarify this better in the specification, as you say. The idea of visibility being set on an upload doesn't really mesh with what Collections were set out to solve. Essentially:
An Upload may belong to many Collections
A Collection may have one of the following privacy levels:
Private: The Collection and its associated uploads are available ONLY to the owner of the collection and any users who have Followed the collection. The Collection owner MUST Accept or Reject any Follow on a private Collection.
Local: The Collection and its associated uploads are available ONLY to the owner of the collection, users on the same domain as the owner, and any users who have Followed the collection. The Collection owner MUST Accept or Reject any Follow requests from remote users on a local Collection.
Public: The Collection and its associated uploads are available to any authenticated user, or to unauthenticated user if the server admin has enabled public browsing. All Follow requests are Accepted automatically unless the requesting user is blocked by the Collection owner.
There may be situations where a user wants to share specific content, such as individual tracks, with very specific users. In these cases, multiple private Collections may be created implicitly by the server. Here's an example:
User A uploads Track A. The track is added to User A's private Uploads Collection by default.
User A shares Track A with User B. Funkwhale does the following:
Implicitly creates a new Private collection (we'll call this "Track Collection") and links Track A to this collection
User B accepts the share by clicking the share link User A sent. The following happens:
User B sends a Follow request to the "Track Collection"
Track Collection automatically Accepts the Follow request
User B can now access the shared track
If a user has a track in a Public or Local collection and chooses to share the track using the mechanism above, it doesn't really matter. Either way, User B will ultimately have access to the specific content that was shared.
If a user puts content in a Public Collection and a Private Collection at the same time, this means the content is ultimately Public because the more permissive Collection's privacy settings will win out. If the user no longer wants the content to be public, they can remove it from any Public Collections. If they do, the permissions of the other Collections will take precedence. For example:
User A adds Track A to a Public Collection, a Local Collection, and a Private Collection
Since Track A is in a Public Collection, it is ultimately visible to all users
User A removes Track A from the Public Collection
Since Track A is in a Local Collection, all local users are able to see the content, but remote users cannot
User A removes Track A from the Local Collection
Since Track A is now ONLY in a Private Collection, only User A and any Accepted followers of the Private Collection can see and interact with the track
Yes I understand this mechanisms and I agree on them. But I think they are not perfect since there is a redundancy between collection and playlist and this doesn't cover the use case describe but georg in this comment and by me in this other comment. Also there is three kind of collection (buildins, users and hidden) this is an headache.
In the forum thread we spoke to merged collection and playlist together. The idea was dropped out because collection were to curate owned content and manage access right https://forum.funkwhale.audio/d/214-whats-wrong-with-libraries-and-a-path-to-fix-them/46.
But since we have to implement a way to share object with a limited amount of user, we could use this feature to only allow playlist has a curate content system and collection has a right management mechanism. This way thing will be more clear for the user and for us as describe in my previous comment.
With the above proposition I see no reason to allow user to create custom collection and to follow them, I see only complication that we will carry for a lot of time, we will have to describe collection to users, explain them, when we could just implement something they are familiar with : playlist and right access management.
@petitminion okay, I think I'm starting to see this a bit more clearly now. In your proposal, a user WOULD NOT create lots of different Collections for different purposes such as Genre/mood/common license, but would instead use them ONLY as a sharing mechanism. They would organize content ONLY in playlists in the same way they do with other services such as Apple Music/Spotify. Am I getting that right?
a user WOULD NOT create lots of different Collections for different purposes such as Genre/mood/common license,
That's it
but would instead use them ONLY as a sharing mechanism.
Mot exactly, only as a right management system to see what is public or not. A track could only be on one of the three build in collection. Sharing will be done through playlists, sharing link or through user follow.
They would organize content ONLY in playlists in the same way they do with other services such as Apple Music/Spotify
A future feature could be to create a "folder" container. But folders would have nothing to do with rights management. They will only be used to put various content type in the same space (playlists, podcasts, artist, channels, etc), collection for right management (we could chamge the name), playlists to curate audio content and sharing.
Mot exactly, only as a right management system to see what is public or not. A track could only be on one of the three build in collection. Sharing will be done through playlists, sharing link or through user follow.
If we have only 3 built-in collections, how would the sharing links work? In the current spec, sharing a track essentially creates a new collection which the targeted user can follow. If we are limiting ourselves to 3 built-in collections, how should this work?
I think I'm also not quite understanding how sharing multiple tracks works in this scenario. Let's say:
User A uploads 3 tracks
Track A goes into their Private collection
Track B goes into their Local collection
Track C goes into their Public collection
User A wants to share all 3 tracks with User B
In this design, how does User A do this? Do they have to create sharing links for each track?
A future feature could be to create a "folder" container. But folders would have nothing to do with rights management. They will only be used to put various content type in the same space (playlists, podcasts, artist, channels, etc), collection for right management (we could chamge the name), playlists to curate audio content and sharing.
This is more or less what Collections are specced to be at the moment, but they combine rights management with organization.
If we have only 3 built-in collections, how would the sharing links work? In the current spec, sharing a track essentially creates a new collection which the targeted user can follow. If we are limiting ourselves to 3 built-in collections, how should this work?
Various things are possible. I would go with a shared_recipients attribute on the Upload objects. But we might find a more optimized way to do it.
In this design, how does User A do this? Do they have to create sharing links for each track?
Either it create a playlist with the three tracks and use an option to share playlist content to a list of recipients (could also be done through a link). Or tracks by track with the individual sharing link
This is more or less what Collections are specced to be at the moment, but they combine rights management with organization.
Indeed, and that is what make them complicated to understand I think.
@petitminion I definitely agree it should be prioritized. I would like @mjourdan to give his thoughts as well to make sure that what we've discussed here works with his designs or if there's something else we need to cover.
Regarding the privacy levels, I think private should be, well, private. So I would see something more like this:
( ) private (owner only)
( ) shared
with followers
with following
with instance users
with anyone (public)
require approval
by link
Regarding the definition of a collection, one distinction I see that separates them from playlists, is that collections are intended to be browsable, like would be an artist profile, a tag, or a whole library.
Either it create a playlist with the three tracks and use an option to share playlist content to a list of recipients (could also be done through a link). Or tracks by track with the individual sharing link
I do think playlists can be used to show other what you listen to, but people must be able to add remote tracks to their playlists. It is the person that has control over that remote track that will allow (or not) access to that track.
A future feature could be to create a "folder" container. But folders would have nothing to do with rights management. They will only be used to put various content type in the same space (playlists, podcasts, artist, channels, etc), collection for right management (we could chamge the name), playlists to curate audio content and sharing.
This is more or less what Collections are specced to be at the moment, but they combine rights management with organization.
Indeed, and that is what make them complicated to understand I think.
To describe collections, tags/labels would be a more appropriate metaphor than folders. Also, they are not intended to organize channels, as those already serve a similar purpose, but for self-made content. If you prefer, collections can be seen as a third kind of channel for content you own, alongside artist channels and podcast channels.
@Sporiff this is blocking various things, I think we should make this a priority if you agree 😄
Regarding the privacy levels, I think private should be, well, private. So I would see something more like this:
It's a great idea to add this new privacy settings : with followers, with following
"required approval" is a bit tricky : we need to have new designs and backend mechanism for this. I would keep all this for another spec.
Regarding the definition of a collection, one distinction I see that separates them from playlists, is that collections are intended to be browsable, like would be an artist profile, a tag, or a whole library.
To describe collections, tags/labels would be a more appropriate metaphor than folders. Also, they are not intended to organize channels, as those already serve a similar purpose, but for self-made content. If you prefer, collections can be seen as a third kind of channel for content you own, alongside artist channels and podcast channels.
Thanks for the clarification, this make things clearer. Why not use playlist with only self-content ?
Do you agree to have a independ system for right management ?
"required approval" is a bit tricky : we need to have new designs and backend mechanism for this. I would keep all this for another spec.
Yeah, I feel the same.
Thanks for the clarification, this make things clearer. Why not use playlist with only self-content ?
Because people expect to be able to add to their playlists whatever track they have access too, without even knowing where it is hosted. Automatically replicating content to one's own library would be an option, but that could consume a lot of storage space: the more someone would listen to other's people track, the less space they would have to upload their own content.
Do you agree to have a indepent system for right management ?
I have no clue of what the code looks like, still I tend to think that makes the sense. Either that, or relying upon what exists for channels. From a user point of view, the sharing/access management/follow feature would work mostly the same for channels and collections. Plus any kind of audio file could be quickly shared by link, or benefit from existing sharing rules by attaching it to one or several collections.
Because people expect to be able to add to their playlists whatever track they have access too, without even knowing where it is hosted. Automatically replicating content to one's own library would be an option, but that could consume a lot of storage space: the more someone would listen to other's people track, the less space they would have to upload their own content.
Yes they expect to be able to add any tracks to a playlist. But nothing block them from only adding content they own. Another option than replicating the content (might be tricky for copyright reasons) would be to provide an option in the playlist, or a badge that show that only owner content is present in the playlist.
Also since we have channels for artist, channels for podcast maybe it's a redundant feature to add collections for users. A user do not "own" content. I think we should define the actor that would use it. I suppose only labels need to curate the content they own in a public way for sharing purpose. In this case we could create a label feature, which would be more clear from my point of views, since it will only allow public content. In the frontend it could be called "Label collection" and in the backend it would be a channel. This way the collection enhancements could be applied to artists channels also.
And the work we have done for collection (the flexibility of the upload process, the sharing mechanisms and the right management mechanism) will be implement in this specification in parallel of playlist featuring
I have no clue of what the code looks like, still I tend to think that makes the sense. Either that, or relying upon what exists for channels
Perfect, we could use your desings of the build-ins collection but rename them to make understand theses container are for right management ? Maybe put them in the user settings and not in the user library ?
Plus any kind of audio file could be quickly shared by link, or benefit from existing sharing rules by attaching it to one or several collections.
From my pov this is what create confusion in the collection feature : sometimes public sometimes private. By only allowing public content to collection like in the channel we would avoid any confusion. The flexibility of the sharing mechanism will be kept thanks to the sharings link feature that could be use for individual or container objects (tracks, album, artists, playlist) and the flexibility to curate content will be done thanks to playlist. Has describe in #2275 (comment 62161) Libraries would be drop in favor or the right management system. Following will only be available for channels (including labels channels), playlists and users.
I don't think a community vote would bring anything useful here. I don't get the idea of renaming the task. In the end it's still about implementing the specs and designs, right?
In the end it's still about implementing the specs and designs, right?
what ? why ? not at all why do you think that ? what wasn't clear in the thead ?
this is about dropping collection in favor of playlist and using libraries/collection for right management (this will allow to follow the new upload spec), and dropping library/collection follow (in favor of playlist follow. Plz see #2275 (comment 62973) just above
what ? why ? not at all why do you think that ? what wasn't clear in the thead ?
Sorry, I thought for a while that you wanted to amend the spec in two ways. The first beiing the term "collection" you had issue with, and the second being isolating the right management system on the technical level.
I'll try to respond to the various points you raised in those two posts, then.
this is about dropping collection in favor of playlist and using libraries/collection for right management (this will allow to follow the new upload spec),
I don't get what you mean by using collection for right management, if collections are ditched anyway. Something like "access control" would probably be a better name for the underlying thing handling the right management.
and dropping library/collection follow (in favor of playlist follow. Plz see #2275 (comment 62973) just above
So, when someone follows a playlist, what would happen? How would that affect their own library? Would the albums and individual tracks appear in the follower's library?
Yes they expect to be able to add any tracks to a playlist. But nothing block them from only adding content they own. Another option than replicating the content (might be tricky for copyright reasons) would be to provide an option in the playlist, or a badge that show that only owner content is present in the playlist.
Yes technically nothing blocks them to do so, but nothing helps them either. Visual cues in the playlist could be a thing, but that would not be enough to make sure all the content they add to a playlist will actually be accessible to the people they share their playlist with.
Also since we have channels for artist, channels for podcast maybe it's a redundant feature to add collections for users. A user do not "own" content. I think we should define the actor that would use it. I suppose only labels need to curate the content they own in a public way for sharing purpose. In this case we could create a label feature, which would be more clear from my point of views, since it will only allow public content. In the frontend it could be called "Label collection" and in the backend it would be a channel.
When you speak of "Label", do you mean it as in the music industry or as a "tag"?
This way the collection enhancements could be applied to artists channels also. And the work we have done for collection (the flexibility of the upload process, the sharing mechanisms and the right management mechanism) will be implement in this specification in parallel of playlist featuring
Are "the sharing mechanisms and the right management mechanism" supposed to be 2 separate things?
Perfect, we could use your desings of the build-ins collection but rename them to make understand theses container are for right management ? Maybe put them in the user settings and not in the user library ?
"uploads, subscribed, shared, private" ? Those could not be containers, but sections on a "sharing" page instead? And under each section would appear cards of albums, playlists, etc.?
Plus any kind of audio file could be quickly shared by link, or benefit from existing sharing rules by attaching it to one or several collections.
From my pov this is what create confusion in the collection feature : sometimes public sometimes private. By only allowing public content to collection like in the channel we would avoid any confusion.
Well, in the collection approach, attaching content to a public collection makes that content public, the same as if it was attached to an artist channel. Collections are not a place where you put already public stuff in it, they are the mean to tell "this whole lot of stuff is public, this one is accessible to X, this other one is accessible to Y". That's why I said in #2275 (comment 62956) that collections could be "a third kind of channel" and in #2275 (comment 62959) that sharing would work the same as in channels.
In your proposal based on playlists, how do you not end up with the "sometimes public sometimes private" issue you describe? On the contrary, we've seen that by nature, playlists mix both.
The flexibility of the sharing mechanism will be kept thanks to the sharings link feature that could be use for individual or container objects (tracks, album, artists, playlist) and the flexibility to curate content will be done thanks to playlist. Has describe in #2275 (comment 62161) Libraries would be drop in favor or the right management system. Following will only be available for channels (including labels channels), playlists and users.
So, playlists would become the way to share bulks of artists and albums at once? Could existing libraries be turned into playlists, to avoid breaking things while migrating to the newer version of Funkwhale?
thanks for responding, your insight is very nice to have o/
I don't get what you mean by using collection for right management, if collections are ditched anyway. Something like "access control" would probably be a better name for the underlying thing handling the right management.
The upload process was design with this is mind, libraries work with this in my too. Also from the backend pov this will look like our actual libraries. So that's why I'm using the collection/library terminology. But I agree "access control" is clearer.
So, when someone follows a playlist, what would happen? How would that affect their own library? Would the albums and individual tracks appear in the follower's library?
Depends on the definition of library. In any case the ownership of the tracks do not change. And we should have a space for my playlist and another one for third party playlists.
Yes technically nothing blocks them to do so, but nothing helps them either. Visual cues in the playlist could be a thing, but that would not be enough to make sure all the content they add to a playlist will actually be accessible to the people they share their playlist with.
When you speak of "Label", do you mean it as in the music industry or as a "tag"?
in the music industry, sorry for the confusion 😄
Are "the sharing mechanisms and the right management mechanism" supposed to be 2 separate things?
Yes. "acces control" is for individual tracks and the privacy levels we spoke about before. While sharing mechanisms is about the sharing links and the follow features
"uploads, subscribed, shared, private" ? Those could not be containers, but sections on a "sharing" page instead? And under each section would appear cards of albums, playlists, etc.?
yes perfectly. but the categories would be our privacy setting levels (me, instance, followers, public and shared by link)
Well, in the collection approach, attaching content to a public collection makes that content public, the same as if it was attached to an artist channel. Collections are not a place where you put already public stuff in it, they are the mean to tell "this whole lot of stuff is public, this one is accessible to X, this other one is accessible to Y". That's why I said in #2275 (comment 62956) that collections could be "a third kind of channel" and in #2275 (comment 62959) that sharing would work the same as in channels.
Attaching content to a public collection makes that content public, but it can also be in a private collection : how does a user manage access rights in that case ? You also describe collection has a way to curate owned content and has you said we already have channels for that.
In your proposal based on playlists, how do you not end up with the "sometimes public sometimes private" issue you describe? On the contrary, we've seen that by nature, playlists mix both.
Yes playlist mix content, it doesn't change the content access right. So it doesn't make content right management complicated. While in collection a track in a public collection would be public even if it's also on a private collection. We mix the container right acces and the content right access. This is what is not clear and what my proposition aims to avoid.
So, playlists would become the way to share bulks of artists and albums at once?
yes. But there would also be the sharing links.
Could existing libraries be turned into playlists, to avoid breaking things while migrating to the newer version of Funkwhale?
And yes this is exactly the migration process I though about. To clone all libraries into playlist, and to assign library privacy level to their tracks.
Attaching content to a public collection makes that content public, but it can also be in a private collection : how does a user manage access rights in that case ?
You also describe collection has a way to curate owned content and has you said we already have channels for that.
Those are different use cases. We have channels for podcasts and artists publishing, so it makes sense to have channels for collection sharing.
Yes playlist mix content, it doesn't change the content access right. So it doesn't make content right management complicated.
Actually they do (in both of our proposal), precisely because they are just pointers that can be used to share visibility without giving actual access.
While in collection a track in a public collection would be public even if it's also on a private collection.
Because that's the collections that are either public or private.
We mix the container right acces and the content right access. This is what is not clear and what my proposition aims to avoid.
In the collection design there is no such distinguo as "container right access" vs "content right access". It seems to me your proposal tries to avoid a non existent issue here.
I wasn't clear enought : I don't find the solution clear enough. We will have to many kinf of collection and it will be confusing. That's why I propose to create a right management / "access control" system that is different from collections.
Those are different use cases. We have channels for podcasts and artists publishing, so it makes sense to have channels for collection sharing.
no necessarely. Since artist and podcast channels are for public sharing owned content. A user do not own music content has I already explained. All other software use playlist to share curate list of content, why not us ?
Actually they do (in both of our proposal), precisely because they are just pointers that can be used to share visibility without giving actual access.
how it is complicate to put only public content in a public playlist ? we could even create a badge to help user be sure all the content of the playlist is public, or provide an option to make all playlist content public.
Because that's the collections that are either public or private.
In the collection design there is no such distinguo as "container right access" vs "content right access". It seems to me your proposal tries to avoid a non existent issue here.
yes and that's what is confusing : the content privacy level is linked to the container privacy level. there is avrious kind of collection (user, built-ins), there is various kind to curate content (collection and playlist) and there is various way to share content (collection and playlist) on top of taht there is a lot of code redundency (We have to code various time things that serve similar purpose) and it create confusion for users (what should i use, collection or playlistor channel ?) so I think there is a lot of issues here
Thanks but we already spoke about each of these features individually and I showed that all this can be also done with playlist so I don't think this respond to the question.
This table illustrates how patterns and behavior differ between these two features to match their respective goals.
Now, if you tweak playlists patterns and behavior to match those described in the right column, then you loose most of the benefits you were aiming for with your proposal, ie: user familiarity, reduced risk of confusion, reduced technical complexity.
Also, I am not certain interoperability is an argument for using playlists as a replacement for collections, as allowing people to share whole parts of their library is not a goal other platforms's share with Funkwhale AFAIK. I mean, whatever people link to in their playlist, the actual access to the file is ultimately granted by the platform owner based on your country of residence and other mysterious criteria, and locked by DRM.
I am all in favor of playlist follow which is good for its own purpose, it's just I am not yet convinced it would be the best fit to replace the old libraries system.
Now, if you tweak playlists patterns and behavior to match those described in the right column, then you loose most of the benefits you were aiming for with your proposal, ie: user familiarity, reduced risk of confusion, reduced technical complexity.
Could you explain exactly why we loose theses benefits ? I don't get why we loose them.
Playlist are more familiar than collection.
There will be no confusion possible since there will be only one way to follow curate list of content and there will be only one way to curate content.
It's really more easy to extend playlist than to build a completely new feature that change right access to objects and that has to be federated..
Also, I am not certain interoperability is an argument for using playlists as a replacement for collections, as allowing people to share whole parts of their library is not a goal other platforms's share with Funkwhale AFAIK. I mean, whatever people link to in their playlist, the actual access to the file is ultimately granted by the platform owner based on your country of residence and other mysterious criteria, and locked by DRM.
Has I explained before, if the goal of collection is to shared content a user own then we already have Channels for that. If user wants to share content they doesn't own I don't think Funkwhale is the right place or at least we shouldn't make this a feature.
@mjourdan@Sporiff@funkwhale/development Considering the lack of response, considering we don't have frontends developers and considering that I need this design to be closed to update the nlnet funding accordingly I will consider this as closed next week.
We will replace collection feature by a "Sharing link" feature. Playlist and user will be the only activitypub objects supporting follows. Libraries will remain has a right management / "access control" system. This mean we will have this tasks to do :
Sharing link for fw audio objects (playlist and later, artist, album, track)
Migrate library to access control : migrate library follow to playlist follows, export existing libraries to playlists. In the frontend drop the library terminology to "Access control". Drop library creation, update and replace it with three build-in libraries (private, public, pod, followers).
I select a track in the Funkwhale interface and click "share"
I choose who to share the track with
Funkwhale implicitly creates a collection for just this track, and grants the user(s) access to the collection
This wouldn't really work with playlists, or at least it would be the wrong nomenclature. People think of sharing playlists as being a specific action, but the idea of needing to add something to a playlist just to share it with their friends seems somewhat counterintuitive.
If funkwhale implicitly creates a collection, we can do the same thing without allowing user to create custom collection. This is not documented is the spec tho'. And in any case I wonder how it will work since collection are owned by a user, not various user. If we want to share a private tracks with only one user we need a right management system that allows it. Curently a library privacy settings are "me", "pod", "everyone". If we want to only share with a specific persons we need a new system. I think it should be another spec before their is a lot of things to discuss about this.
Also if you want to share non curated content, your friend could follow your user account, they will see every new public upload you do (need to be added to the user follow spec)
However, if we offer both I think that people do actually want to use both.
Why ? What collection have that playlist don't ? isn't it confusing to have two similar way to share content ?