Link to tracks that aren’t on Funkwhale

petitminion

maybe we could even be more verbose and explain that if the pod is not federated a lot, lots of content might be missed

mjourdan

Such explanation seems interesting for the admin panel. For users without privileges, it's best to keep it short as there is not much they can do anyway.

petitminion

If nobody has has something to add I think we could start coding this next week.

petitminion

mjourdan I think its important that the user understand some instance a not globally federated while some others are. They can try and use another instance

mjourdan

Migrating from one instance to an other is a bargain. Advertising such possibility will make more sense the day we offer the proper tooling to find a better instance, and to actually migrate the data and account information.

petitminion

mjourdan For me it's not advertising for such a thing. Saying "this pod cannot find this content" is just describing the reality while saying "there is not such content in the network" is maybe telling a lie. I'm only suggesting to be accurate.

mjourdan

petitminion

The mockup reads "this content could not be found on the Funkwhale network", so I don't think it is any less accurate than "this pod cannot find this content"?

petitminion

mjourdan I think it is. Has I said, “this content could not be found on the Funkwhale network” means the funkwhale network doesn't have this content. “this pod cannot find this content on the Funkwhale network” means the content might exist on the funkwhale network, but we can't find it on the actual pod

Sporiff

I think we need to focus on the simplest mechanic here: adding links to content metadata in Funkwhale to make it more useful to users. We can think about adding things later on down the line, but I believe the most important use cases for right now are just giving artists who upload to Funkwhale the ability to:

Link to their website
Link to a store where you can purchase their content
Link to external media such as music videos
Link to social media
Link to external streaming services

From my perspective, the user experience here is:

I am a user
I see a track listing in Funkwhale for "Dancing Queen" by ABBA
I don't own an associated upload, so the track is unplayable
I can look at the links in the track overview to:
- Stream the song elsewhere to see if I like it
- Purchase the song from the artist

I'm drafting a spec for this here to cover how we might want to handle this.

Sporiff

The spec draft is more or less complete. There are probably some edge cases I've not considered or pieces missing, but the main bits are done. We still need to answer the question of how a user who is not a library admin can suggest changes in API v2, but that's something we should spec separately.

Please check it out and leave your comments here.

https://pad.funkwhale.audio/VyGBZFb4T5G57q-99pApGQ

petitminion

Sporiff The spec is great o/

Why implement links edition in funkwhale (post, update links) when users could tag theirs files directly or better edit the musicbrainz page ? This will be usefull for professional that are looking for a standardized way to spread their work. I think we should encourage producer to user a centralized service / tagging convention like musicbrainz to do so. This way their file will be compatible with other services and not only with funkwhale.

In this scenario Funkwhale would only import file metadata or get the links from Musibrainz. This also avoid us a lot of work and do not change the functionality of the feature.

This also have another advantage : we do not need to bother with moderation and scam links. This will be done by the musicianship community. One pod admin that sees a bad link will update the metadata on mb, this will propagate to all funkwhale pods automatically.

mjourdan

petitminion

Why implement links edition in funkwhale (post, update links) when users could tag theirs files directly or better edit the musicbrainz page ?

Because Funkwhale needs so much reliable metadata, tagging is part of the Funkwhale experience. So I think this is something we should handle somehow, rather than setting it as an entry barrier in front of people who just want to have their audio online.

I wonder

how much of a burden it would be if we were pushing the links from Funkwhale to MusicBrainz, in terms of moderation?
would that have privacy implications if we made it a strict requirement to push those metadata to MB for tracks with an MBID?

This also have another advantage : we do not need to bother with moderation and scam links.

The issue would not totally be avoided I believe, as such links could still be placed in channels descriptions or user profiles.

One pod admin that sees a bad link will update the metadata on mb, this will propagate to all funkwhale pods automatically.

What if the admin could fix the link right through Funkwhale?

petitminion

mjourdan

mjourdan Because Funkwhale needs so much reliable metadata, tagging is part of the Funkwhale experience. So I think this is something we should handle somehow, rather than setting it as an entry barrier in front of people who just want to have their audio online.

This wouldn't be a barrier, song still could be uploaded without any problems. From my pov tagging is not part of funkwhale. I use fw to discover music, not to tag my file because their is so better tools for this than fw.

mjourdan how much of a burden it would be if we were pushing the links from Funkwhale to MusicBrainz, in terms of moderation?

I which name this will be done ? The fw pod admin would have to create a mb account and will became responsible for theses links. If we use the user account, the user will have to link his account, instead of using mb directly.

mjourdan would that have privacy implications if we made it a strict requirement to push those metadata to MB for tracks with an MBID?

We could follow the privacy setting of the track for this.

mjourdan The issue would not totally be avoided I believe, as such links could still be placed in channels descriptions or user profiles.

not totally indeed, just partially.

mjourdan What if the admin could fix the link right through Funkwhale?

For me it's just useless, why have a fw ui to make edits to mb when you can make them directly in their website ?

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.

« Previous Page Next Page »