Playlist federation

petitminion

petitminion @mjourdan we need a desing for this has well... So much thiiiings o/ Do not forget that if you want you can track your working time into gitlab so we can share the fundings accordingly 🙂

mjourdan

Sporiff

So “Subscribe” or “Follow” feels appropriate.

Totally.

I’m not sure about this from a UX perspective. In my head, all content is part of a collection. A playlist refers to content in different collections. As a user, my expectation is that if I add content to a playlist, it should inherit the visibility of the collection it’s in.

On the other hand, you can attach each track of your library to several collections. So we could imagine that you would do the same with your playlists. Then, all tracks from that playlist hosted in your library would inherit your collection permissions, while the playlist would only share pointers of remote-hosted content.

As a side note, we need to bring some refinements to the copy around the "visibility" idea, as a track might be listed somewhere without beeing readable.

As a user, I could add content that’s hosted on my pod to a playlist. It might belong to me, it might not. It’s not my choice to give other users access to that content.

I would say if the content is stored in your library, it's your choice.

So, I think what I’m saying is that the content in the playlist should inherit the visibility and permissions of its containing collection. If it’s public, then anyone can add it. If not, users that don’t have access should only see the metadata of the entry but not be able to play it.

One detail: there are cases when people might not have access to a track through a first collection, but have it through a second one. In that case, it's important the track can be played seamlessly right from the playlist.

gcrk

I agree to the idea of playlists just being an ordered set of pointers to tracks. Therefore, a playlist has nothing to do with weather or not a track is playable. Its just a list of tracks.

I got the intention that you expect a playlist to be part of a collection, but why would it be? Isn't it an independent concept? Why would I add a playlist to a collection? I probably want to set visibility for a playlist on its own, independently from a collection it might be part of?

Sporiff

gcrk

I got the intention that you expect a playlist to be part of a collection, but why would it be? Isn’t it an independent concept? Why would I add a playlist to a collection?

I don't think a playlist should be part of a "Funkwhale collection" in the way that recordings/releases/artists are. Instead, the playlists you follow should be grouped together in a view in the interface so you can easily find the playlists you follow.

Maybe it would be nice to be able to add all tracks in a playlist to a collection(s), but that's about as far as I can see that going.

I probably want to set visibility for a playlist on its own, independently from a collection it might be part of?

Yes, a playlist's visibility should be separate. However, the visibility of the content inside the playlist needs to respect its containing collection(s). The following scenario is a good example: let's say

@sporiff invites @georgkrause and @mjourdan to follow a private collection
@georgkrause invites @sporiff to follow a private collection.

Next, @sporiff creates a playlist containing the following:

Content from a public collection
Content from @sporiff's private collection
Content from @georgkrause's private collection

@sporiff sets the visibility of the playlist to Private, and shares it with @mjourdan. In this scenario, @mjourdan has access to:

The public collection's content
The content in @sporiff's collection

@mjourdan does not have access to:

The content in @georgkrause's collection

In this case, @mjourdan should be able to see all tracks listed in the playlist but only able to play the content they have access to. This means that the playlist respects:

The visibility level assigned to the playlist itself
The visibility level and access control of the content contained in the playlist

petitminion

So I think we all agree that playlist content shoudn't follow playlist visibility.

I think we will have mostly everything we need for the spec after ageing on the endpoints :

POST /playlists/{guid}/follow_request : make a follow request to the playlist actor
DELETE /playlists/{guid}/follow_request/{uuid_of the follow} : unfollow
GET /playlists/{guid}/followers : get the followers of a playlist (how should we handle access to this information ? only for the owner of the playlist ? )
From the https://dev.funkwhale.audio/funkwhale/api-v2-specs/-/merge_requests/1/diffs GET /playlists : return playlist from the server. so we could use GET user/me/playlists to return owned playlist
GET user/me/playlists/following : return user's following playlist

petitminion

so considering this : https://dev.funkwhale.audio/funkwhale/funkwhale/-/issues/1810#note_63349 I propose to follow our actual api structure to get this done. It is accessible here : https://docs.funkwhale.audio/swagger/#/

Since everything on the backend is done I will write a backend spec and start implementation.

We need a frontend design @mjourdan but this is likely to be influenced by our discussion about collection https://dev.funkwhale.audio/funkwhale/funkwhale/-/issues/2275#note_61336

mjourdan

petitminion

We have a "Federation" page in the server settings here:
https://design.funkwhale.audio/#/view/e3a187f0-0f5e-11ed-adb9-fff9e854a67c?page-id=c0288ed0-3133-11ed-85c2-f7fcc1c1427c&section=interactions&index=0&share-id=05904d10-40d8-11ed-b91a-c19cdb5a453b

And a popover to share a given playlist there:
https://design.funkwhale.audio/#/view/e3a187f0-0f5e-11ed-adb9-fff9e854a67c?page-id=6ca536f0-0f5f-11ed-adb9-fff9e854a67c&section=interactions&index=0&share-id=0b1bb873-5fc1-8192-8003-09085485d750

Feedback welcome!

petitminion

spec : https://pad.funkwhale.audio/Yc3SKXyUSK2R1v2-zP_W9w

petitminion

lets continue the discussion here : https://dev.funkwhale.audio/funkwhale/funkwhale/-/merge_requests/2785

if nothing is added to the discussion I will start implementation when I have time

petitminion

Thanks for this new designs !

visibility level :

I would rename this " Content visibility" and put this in a different menu than "sharing playlist" to make clear this is about sharing the content. I would also use a more clear terminology like :

change the visibility of the all the tracks I own in this playlist to : private / public / followers / pod etc.

federation :

we should speak about this in https://forum.funkwhale.audio/d/209-domain-follow-feature/6

mjourdan

petitminion

I would rename this “ Content visibility”

I just tried the following: changed "playlist audience" for "playlist visibility", and changed "content visibility" for "content sharing".

and put this in a different menu than “sharing playlist” to make clear this is about sharing the content.

Where, then?

I would also use a more clear terminology like :

change the visibility of the all the tracks I own in this playlist to : private / public / followers / pod etc.

What happens to the visibility of the tracks belonging to remote sources?

we should speak about this in https://forum.funkwhale.audio/d/209-domain-follow-feature/6

Right.

petitminion

mjourdan I just tried the following: changed “playlist audience” for “playlist visibility”, and changed “content visibility” for “content sharing”.

yeay its more clear for me o/ But the sentence "allow or forbid to listen to your plalist" is confusing : this is not about the playlist, it's about the content in the playlist. So it should be "allow or forbid people to listen to the playlist content you own"

mjourdan Where, then?

a different menu that is not called "Share playlist" but rather "Manage right access to this tracks" or "Content access rights"

mjourdan What happens to the visibility of the tracks belonging to remote sources?

nothing. We can't change that. but if its there is probably public anyway 🙂 and there is also this solution : https://forum.funkwhale.audio/d/607-listen-to-third-party-tracks