Link to tracks that aren’t on Funkwhale

Sporiff

Once again, I think we need to consider that users may not want to rely on MusicBrainz, and it's not a good UX to leave Funkwhale to add tags or links. I'm definitely in favor of getting links from MusicBrainz if the content is tagged with an MBID, and I think the admin should have the option to run a task periodically to keep these links up-to-date as mentioned in the spec, but there does also need to be a way for users to add/edit links for both MBID and non-MBID content.

Some users may not even really understand MusicBrainz, or know what it is. The process of editing content on MusicBrainz isn't the most user-friendly, so asking users to leave Funkwhale to go to MusicBrainz just to add a link seems like really bad practice from a UX perspective. Funkwhale users are here to use Funkwhale. They want to upload content and organize it in Funkwhale. MusicBrainz is a helper to get good metadata during upload, but beyond that I don't think most users even think about it.

Similarly, I don't think Funkwhale should send new links or edits to links to MusicBrainz because that just puts undue load on the MB team to check all of them.

petitminion

Sporiff if we want do this we need to have a way to make the difference between user links and mb links. I'm not against this. If your think it's important let's do it.

Sporiff

petitminion I’d suggest we add an mbid field for the links. MB links have a GUID that we can store and use to deduplicate, then we can just say that if a user enters it, it will have no MBID.

We would need a mechanism to prevent updated links being overwritten when the CLI is used, possibly a Boolean flag that we can use to filter any links that have been updated in Funkwhale.

I can write something up later, but I’m currently on a bus 😜

petitminion

If two users both upload the same content with different links, how can this be resolved?

both link could be displayed ?

How can we prevent users from posting abusive links e.g. links to adult content?

We could create a moderation database that has a list of banned url. BUt this should be another feature cause its complex.

We could also allow admin to disable links edition

Sporiff We would need a mechanism to prevent updated links being overwritten when the CLI is used, possibly a Boolean flag that we can use to filter any links that have been updated in Funkwhale.

Why not have both ? And make clear on the ui what comes from mb and what come from fw users ?

If nobody is against this I would like to start coding the api next week, cause I'm stuck in my other tasks.

petitminion

Could we replace the cli command to refresh mb links by a task ? This would avoid to have to think about this has an admin and will make sur elink get updates from time to time

Sporiff

Could we replace the cli command to refresh mb links by a task ? This would avoid to have to think about this has an admin and will make sur elink get updates from time to time

As long as we give the admin control over the task, I think this is a nicer approach 👍️

Why not have both ? And make clear on the ui what comes from mb and what come from fw users ?

Yeah we can definitely have both and make a visual distinction. I'm just thinking of the following scenario:

We sync links from MusicBrainz when a new track is uploaded
The server admin sees a link on the track they don't want to display or that they think is incorrect
The server admin updates the link in Funkwhale

In this scenario, the task that updates the links from MB should not update the modified link. It should only touch links that have not been modified on the Funkwhale side.

petitminion

Sporiff
I think update the mb link in funkwhale make no sense if we keep both mb link and fw links (the mb link will not be updated, it will be ignore). In the scenario you describe I think we should add the ability to hide mb link. And I would suggest to add a warning to encourage admin to update the links directly on mb side so their work in usefull for everybody and not just their instance.

Sporiff

petitminion Okay, I think hiding it is a good solution (we can add a flag on the object representation on the API).

And I would suggest to add a warning to encourage admin to update the links directly on mb side so their work in usefull for everybody and not just their instance.

Yeah I see no reason we couldn't link directly to the object on MB to suggest making edits there 👍️ As long as it's optional, it's a nice feature to have.

petitminion

@Sporiff is this closed ? https://pad.funkwhale.audio/VyGBZFb4T5G57q-99pApGQ

petitminion

I added the hide attribute and the source attribute to the spec, so admins can hide a link and the frontend can know were it come from

petitminion

the api probably lack some logic to handle the moderation, I propose to create a list of banned link only editable by the admins. This way if a link is banned even if a user tries to add it again, it will no be allowed, avoiding moderation work.
this is a comes has a complement of admin being hable to edit links

Maybe hide and ban could follow the same logic : the moderator could ban musicbrainz links like any other link instead of hiding them.

Sporiff

petitminion the api probably lack some logic to handle the moderation, I propose to create a list of banned link only editable by the admins. This way if a link is banned even if a user tries to add it again, it will no be allowed, avoiding moderation work.

A denylist is definitely a good idea!

Maybe hide and ban could follow the same logic : the moderator could ban musicbrainz links like any other link instead of hiding them.

I see this mechanism working as follows:

The admin would maintain a denylist of links (e.g. if the admin doesn't want any Wikipedia URLs to appear, they can add it to the denylist and any URLs matching the pattern will not be allowed/will be removed from content. This removes the entry from the database completely, ensuring it's not visible to API responses
The admin can hide specific links from MB if they don't find them relevant or just don't want them to show up. This is different in that it only impacts the specific target (e.g. the album/artist that the admin is editing) and is just there to stop the MB fetch task adding the link each time. This only hides the link visually, and it will still be available in the API response (with a hidden attribute)

Of course, the admin could denylist a specific link that they really don't want appearing in the API response, but that's their choice.

petitminion

Sporiff what is the interest of having both approach ? why not only have a denlist to avoid useless moderation option ?
To have a synced mb table, a tasks would just have to add the hiden atributre to the mb link if a mb link is added to the denlist. The api should not return hiden links (useless explicitly asked to). And that's it. What do you think ?

Sporiff

petitminion It may not be necessary. The only thing I can think of is the following:

There is a link against an artist in MusicBrainz. We pull this link in when we create the artist
The admin of the server doesn't want this link to appear against this specific artist, so they hide it. This means that it isn't displayed against this specific artist even if it's updated
The same link is also present on another artist. The admin does want it to appear here, so they leave it in place.

If we only had a denylist, this wouldn't work. The link would be present on the denylist and so would not appear on any content.

The difference, I think, is between content organization and anti-abuse. The denylist would be an anti-abuse feature, while hiding would be a content organization feature. However, this is probably an edge case, and the denylist is by far the more important mechanism. Maybe we should start with that and just have the link hiding feature be a future feature idea.

petitminion

Sporiff If we only had a denylist, this wouldn’t work. The link would be present on the denylist and so would not appear on any content.

Indeed..

Sporiff Maybe we should start with that and just have the link hiding feature be a future feature idea.

I agree with that o/

petitminion

So about the denlist, it should be accessible in the moderation section I suppose ? We can also keep this frontend design for later and only provide it through the django admin panel

I'm gonna start coding the backend api endpoints for this feature

Sporiff

petitminion I think it's important that this is easily accessible for end users, so as soon as possible we need to expose it in the application itself to ensure that admins can easily control this. The Django admin panel is fine while we're still developing the feature, but we can't reasonably expect admins to keep using it for day-to-day stuff.

petitminion

Sporiff @mjourdan this means we need another design here 🙂

gcrk

@petitminion I don't think we need this for now, we have widgets that should be used and if I remember correctly there is already a design pending for the admin settings, but they would only get picked up when Kasper is doing the reimplementation of the settings page.

petitminion

gcrk okey thx for lettings me know 🙂 Could be great if all the team could have access to the design through penpot directly ? I don't have access to anything in my penpot account :s What do you think @mjourdan ?

gcrk

petitminion You are editor of the group, so you should have access unless you created a new account.

« Previous Page