Against Far right filter : arguments
An issue to track arguments against an hard coded far right filter
Activity
The feature state that people of different viewpoints aren't welcome to the funkwhale community. Which is againt the COC :
to give *everyone* an accessible and ethical gateway to music and audio content.andWe must make room for people who are not like us to enter our field and succeed there. This means not only inviting them in, but making sure that they are supported and empowered.Only viewpoints that goes against our CoC are not welcome. We will not check people ideologies, we are only checking music groups coherence with our Coc. Everybody is welcome unless they don't follow our Coc
😄 Also be aware of this CoC rule :
[IS prohibited] Any attempt to present “reverse-ism” as examples of oppression. Examples of reverse-isms are “reverse racism”, “reverse sexism”, “heterophobia”, and “cisphobia”.Rejecting fascism is not being a fascist.Edited by petitminion
If you want to add another genre that goes againt our CoC you can propose it in our communication channels (Matrix, mattermost, gitlab, forum)
Edited by petitminion
This enforce our collective Coc over all other users. If you don't agree to our CoC you should leave. We hope that all our user share our values against discrimination and fascism.
Edited by petitminion
Banning nazi music is just a first step. Beware of the first step. It always leads to the next one.
Edited by petitminionThis is not an authoritarian decision. We are following collectively build rules. So we don't see what the "next step" could be.
Edited by petitminion
This argument present the feature has going against freedom. We do not have a liberal approach of the freedom concept and we don't have anything in our CoC against censorship. What we do have in our Coc is a feminist approach and it appear feminism is against liberalism. At least our feminism is but since this isn't explicitly stated in our CoC it could be debated.
That being said a feature allowing user or admin to filter content based on genre could be created :)
Edited by petitminion
marked this issue as related to #2395
This is a political belief and our current CoC are very political. Funkwhale is against fascism, we're not free from political belief and nobody is (every institution has a policy).
Edited by petitminion
Hello, I am an admin of a funkwhale instance with 10 users.
I am a huge fan of metal. The change proposed here will directly affect me and my instance. I listen to Burzum, and I am not a neo-nazi. As a queer, social anarchist, person of colour, I am probably the furthest thing from that. While Varg Vikernes himself is a terrible person, he does not taint Burzum's music with his political views. I think there is a huge difference between enjoying art created by a terrible person, and supporting art that itself contains a terrible message. Enjoying art does not necessitate supporting the artist or any of their views. I also listen to Lyube, but I am against the invasion of Ukraine. I listen to Infected Mushroom, but I am against the genocide of Palestinians. I listen to Richard Wagner, but I am not an antisemite. I probably listen to some artists that support Trump, but I am against the fascist takeover of America.
I do welcome the idea of better tools for filtering content that one might find objectionable, but I think these tools should be controlled by the community, instance admins, and end-users rather than the maintainers of the funkwhale software. The proposed feature is also completely ineffective as a pre-emptive policing tool, since users uploading filtered music can either not tag it with musicbrainz IDs, or just modify the ID while tagging with Picard. This will mainly just inconvenience people like myself, and feels more like a performative action than anything.
In my opinion, a much better solution would be something similar to Easylist. A "Filters" subview in the instance moderation view could contain a list of filter lists. Each filter list would have a name, URL, and a checkbox for whether it is enabled or disabled, with more being able to be added by instance admins. Each URL would point to a txt file. This text file would be similar to Easylist, containing a list of MusicBrainz IDs separated by newlines rather than URLs and DOM elements. A cron task could periodically fetch the filter lists to update them. This would empower the community by allowing greater control over the filters, and promote collaboration on filter lists. People like me who may listen to Burzum but are fine with filtering NSBM bands with objectionable content could create a filter list that is a subset of the currently proposed one. The funkwhale maintainers who would like to create filter lists like the Far-right filter still could do so, and could even have them pre-added into this filter list subview (disabled by default, I would hope) to still promote funkwhale's anti-fascist message. The funkwhale maintainer-endorsed filter lists could live in a repo on this gitlab, and a runner could update them from Wikidata like your current method. This way they will also be more resistant to vandalism than the current method. If you think this idea is agreeable I would be willing to help contribute to its implementation, just so that the current proposal will not be implemented. I think a similar implementation for community playlists could be an interesting thing to consider as well.
I hope more maintainers and other members of the funkwhale community will publicly comment on this proposal. I don't mean this as an attack and I appreciate the work you and other maintainers do on this great software, but as it currently stands in the forum and the gitlab issues it feels like this proposal is a unilateral push by you, petitminion, and I would hope to see a lot more support for it in order for it to be merged. I hope we can come to some sort of compromise at the very least, because I am vehemently against the proposal as it currently stands.
(P.S. I would have posted this on the forum, but I never received a verification e-mail and get the errror "Oops! Something went wrong. Please reload the page and try again." when trying to get the server to resend it.)
thanks its nice to have a this pov raised o/ Also nice to see we both like burzum music jaja
Could you explain what makes you "vehemently" against the filter ? I just what to be sure what is the main argument from your pov.
-
There is a huge difference between enjoying art created by a terrible person, and supporting art that itself contains a terrible message.
I didn't have a look at it but if Burzum is classed has neo nazi it's probably because its author is a famous nazi. But I don't see so much cases for which it's a problem. For my personal tastes, only this artist is concerned so I can live with that. But this raise the question of the definition of what is neo-nazi music and how we moderate the list.
-
These tools should be controlled by the community, instance admins, and end-users rather than the maintainers of the funkwhale software.
First of all the maintainers doesn't control the list, it's the wikidata community and any person willing to moderate the wikidata list that will build the list. Then should we let admins or users listen to nazi content ? I would say no. Why do you think we should ?
-
The filter is ineffective if the attacker change the musicbrainz id
It's partially true. The new version will bring musicbrainz id mandatory option. And in a federated context, track without a mbid are less visible. So even if an attacker cheat, it will have an effect. Also an attacker could fork the project, change the code and run it's own version of funkwhale. But they will still not be able to federate the tracks.
- Classic moderation filters
I think you proposition is nice o/ But it's not the same feature. It's not radical enough from my pov. Anti fascism is not an option from my pov. I think it would be more interesting to bring the debate on wikidata if burzum music is neo nazi music since the music itself doesn't contain reference to this ideology. This make me think we could create another feature that block artists thats are neo nazi to share links on Funkwhale, to be sure they cannot use funkwhale to sell stuff and get money. But well, this is more work, I would prefer to accept I will not be able to listen to one or two artists on Funkwhale rather than having to do all this work. There is a lot of nice music to listen, I will survive not listening to Burzum ^^
- I would hope to see a lot more support for it in order for it to be merged.
I also would like to see more support o/ For this but also for everything else (like fixing the email verification issue we have for example). This is a collective project so anyone who wants can join the effort :) This feature has been supported by various persons (we already had the burzum debate/sadness jajaja) but I'm very happy to have this conversation publicly. I was hoping to have more interest in this thanks for joining :)
-
I opened the debate about burzum in the dedicated wikidata page : https://www.wikidata.org/w/index.php?title=Talk%3AQ193172#Nsbm
-
Could you explain what makes you "vehemently" against the filter?
I refuse to allow you to dictate what me or my users may listen to on my funkwhale instance. If other admins would like to ban the same artists that you would like to on their instances, that is totally okay with me. And if having Burzum on my server would be a reason to defederate from my instance, that is fine with me as well. I think there is too much nuance to this issue to hard-code it into funkwhale.
-
I didn't have a look at it but if Burzum is classed has neo nazi it's probably because its author is a famous nazi. But I don't see so much cases for which it's a problem. For my personal tastes, only this artist is concerned so I can live with that. But this raise the question of the definition of what is neo-nazi music and how we moderate the list.
The classification isn't necessarily incorrect. Varg Vikernes is definitely a neo-nazi (even though he refuses the label), but the music itself is separated from that. Feel free to read through the lyrics if you think that is not the case. I think there is too much nuance to this issue to enforce a hard-coded ban like this. I have not looked through your list fully, but I know that Burzum is on the list. I refuse to have this artist banned from my server for no benefit.
-
First of all the maintainers doesn't control the list, it's the wikidata community and any person willing to moderate the wikidata list that will build the list. Then should we let admins or users listen to nazi content ? I would say no. Why do you think we should ?
The maintainers would control the list being hardcoded into funkwhale. I think we should let admins control what is allowed on their server, since their definition of nazi content may differ from mine or yours. The users can listen to whatever their instance admins are willing to platform. I think that Israel is a far-right fascist state, why shouldn't Israel music be included in the Funkwhale far-right filter? I think a similar idea to this that I am also against would be forcing instances to federate with another instance that shares our personal politics. Control shouldn't be taken away from instance admins, and I think doing this would go against the decentralized and federated raison-d'etre of Funkwhale.
-
It's partially true. The new version will bring musicbrainz id mandatory option. And in a federated context, track without a mbid are less visible. So even if an attacker cheat, it will have an effect. Also an attacker could fork the project, change the code and run it's own version of funkwhale. But they will still not be able to federate the tracks.
Even with mandatory musicbrainz IDs, attackers could replace the tags with valid or invalid IDs. Since there are so many ways to bypass the filter, I think implementing it the current way is not worth it. Implementing it as filter lists to be used as a tool to assist moderation would help more.
-
I think you proposition is nice o/ But it's not the same feature. It's not radical enough from my pov. Anti fascism is not an option from my pov. I think it would be more interesting to bring the debate on wikidata if burzum music is neo nazi music since the music itself doesn't contain reference to this ideology. This make me think we could create another feature that block artists thats are neo nazi to share links on Funkwhale, to be sure they cannot use funkwhale to sell stuff and get money. But well, this is more work, I would prefer to accept I will not be able to listen to one or two artists on Funkwhale rather than having to do all this work. There is a lot of nice music to listen, I will survive not listening to Burzum ^^
I think this is where most of our disagreement comes from. I think your approach is too radical. I agree that anti-fascism is not an option, but anti-fascism is too nuanced. There are different kinds of fascism, and your definition may be different than mine which is okay. But I think imposing your view of it on others is not okay. I refuse to let moderators of wikidata decide what I may listen to. Having an official anti-fascist funkwhale filter list that admins may subscribe to would still promote anti-fascism while not centralizing moderation. I think that centralization is not an option in regards to funkwhale.
-
I also would like to see more support o/ For this but also for everything else (like fixing the email verification issue we have for example). This is a collective project so anyone who wants can join the effort :) This feature has been supported by various persons (we already had the burzum debate/sadness jajaja) but I'm very happy to have this conversation publicly. I was hoping to have more interest in this thanks for joining :)
Thanks for being open to criticism and being open to disagreement. I realize that you are coming from a good place in your heart.
The e-mail verification worked for Gitlab, just not the forum.
-
- I refuse to allow you to dictate what me or my users may listen to on my funkwhale instance. I
I'm not dictating anything... There is nuance about if burzum is neo nazi content indeed. But burzum will not be banned from Funkwhale unless the wikidata community define it's neo-nazi
- I have not looked through your list fully
Its not my list. I only build a data query service. The list is from wikidata. You can have the full list using this wikidate query here
- The maintainers would control the list being hardcoded into funkwhale.
That's not true. There will be no artist list hardcoded in funkwhale. The only hardcoded thing will be the query to wikidata to get the list of artist. This task can be launch manually by the admin to update the list to the last wikidata state. And a fallback, static (but manually updated) list will bee available in funkwhale.audio in case wikidata get attacked.
3.1. Control shouldn't be taken away from instance admins, and I think doing this would go against the decentralized and federated raison-d'etre of Funkwhale.
The only control that is taken away is the ability to listen to nazi music, how is that a problem ? I respond about the federated dimension later.
- Even with mandatory musicbrainz IDs, attackers could replace the tags with valid or invalid IDs. Since there are so many ways to bypass the filter, I think implementing it the current way is not worth it. Implementing it as filter lists to be used as a tool to assist moderation would help more.
If they use invalid id, federation will break and a lot of local features will break. If they use no id, federation will break with instance forcing mbids. I don't think we can say moderation list would help more since it's not the same feature. But I still agree it's also a nice feature to have
- I refuse to let moderators of wikidata decide what I may listen to. Having an official anti-fascist funkwhale filter list that admins may subscribe to would still promote anti-fascism while not centralizing moderation. I think that centralization is not an option in regards to funkwhale.
Since wikidata is a community platform, since everybody can moderate the content the moderation is not centralized. The definition of neo-nazi and the list is collectively builded, so I don't think we can say it's centralized. The infrastructure is centralized true. But it a different issue. If you wanted Funkwhale to only rely on decentralised infrastructures it's already not the case we rely on : musicbrainz, archive.org, docker, nginx, gitlab,flarum,mailcow etc etc this list is infinite ^^
That being said I understand we would be building an interdependence between Funkwhale and Wikidata. I understand that you might not want to trust wikidata. But if so, why do you trust us ? Using a software developed by other requires trust an interdependence anyway. This is only a special kind of relationship, one we probably never saw. But that could lead to very nice and unexpected things I think.
It's like saying : "hey folks, you give your data to a software using libs you didn't knew about and developed by anonymous people all around the world, running in a place you know nothing about, with people having access to your server but you and your admins don't know them. Since you're this crazy we though you could also trust we can collectively build a list of nazi content so nobody on the network have to listen to this crap"
- Thanks for being open to criticism and being open to disagreement. I realize that you are coming from a good place in your heart.
The feeling is shared :)
Edited by petitminion- I'm not dictating anything... There is nuance about if burzum is neo nazi content indeed. But burzum will not be banned from Funkwhale unless the wikidata community define it's neo-nazi
I meant "you" more so in the generic sense (as in "anyone"). But in this case, you as a maintainer are dictating that the wikidata community should control what my instance may listen to. I think Burzum is not neo-nazi content, the wikidata community may come to a different consensus. I think both viewpoints are valid, but your solution disregards mine. Even if the wikidata community consensus agrees with me that Burzum does not produce neo-nazi content, there may be other bands that we disagree about. Just because the wikidata community might come to a consensus, doesn't mean it is the singular truth. This is one of the reasons community governance of a decentralised, federated platform should not be centralized.
- That's not true. There will be no artist list hardcoded in funkwhale. The only hardcoded thing will be the query to wikidata to get the list of artist. This task can be launch manually by the admin to update the list to the last wikidata state. And a fallback, static (but manually updated) list will bee available in funkwhale.audio in case wikidata get attacked.
Well that is merely a redirection. The only difference between having the list hardcoded into funkwhale and having a wikidata query hardcodede is that it is easier to update the list with the query. It is similar to fetching the list over http instead of the local filesystem.
- The only control that is taken away is the ability to listen to nazi music, how is that a problem ? I respond about the federated dimension later.
It is a problem because people have different definitions of what may be considered nazi music, and this is disregarding the control of admins over moderation.
I think we can both agree that anti-sexism, anti-racism, anti-homophobia, et cetera are also not optional. If hardcoded lists (or wikidata queries) for these were implemented into funkwhale, they would have far-reaching negative effects on its usability. An anti-sexism filter could filter out half of the hip-hop genre. Would Tyler, The Creator's music be considered homophobic because he used homophobic slurs, or would it be fine since he later came out as bisexual? I have some friends that think the n-word with the "a" ending should be considered as inappropriate as the hard-"r" ending, should any music that contains that word be included in the anti-racism list? If not, are these friends of mine wrong to think that? I think there are multiple valid viewpoints to all of this, and enforcing a carte blanche filter for any of these over the entire funkwhale community is the wrong way to go about things. Just because these filters are not forced in funkwhale doesn't make racism, sexism, homophobia, neo-nazism, etc "an option".
- If they use invalid id, federation will break and a lot of local features will break. If they use no id, federation will break with instance forcing mbids. I don't think we can say moderation list would help more since it's not the same feature. But I still agree it's also a nice feature to have
The current proposal is similar to DRM in my opinion. It punishes admins (like me) who would like to use the upstream funkwhale source, by deleting and filtering my instance's music using someone else's definition of nazi music. Meanwhile bad actors have several ways to get around it, and can fork the codebase to disable the filter and have a better experience. If the current proposal was implemented, I myself would switch to a fork that removes the commit. I will continue allowing my instance to listen to Burzum regardless of the wikidata consensus. The moderation lists idea would give admins full control over the moderation of their instances, while still enabling the filtering of neo-nazi content. It would also enable more powerful filtering by allowing the use of multiple filter lists, rather than having to hard-code each list (or hard-code each query) into the codebase. Sure, bad actors could still fork the code or do what I said previously to get around the ID blocks, but that is also an unavoidable flaw in the current proposal. I fail to see any drawbacks with the moderation lists idea, while I have already stated my issues with the current proposal.
- Since wikidata is a community platform, since everybody can moderate the content the moderation is not centralized. The definition of neo-nazi and the list is collectively builded, so I don't think we can say it's centralized. The infrastructure is centralized true. But it a different issue. If you wanted Funkwhale to only rely on decentralised infrastructures it's already not the case we rely on : musicbrainz, archive.org, docker, nginx, gitlab,flarum,mailcow etc etc this list is infinite ^^ That being said I understand we would be building an interdependence between Funkwhale and Wikidata. I understand that you might not want to trust wikidata. But if so, why do you trust us ? Using a software developed by other requires trust an interdependence anyway. This is only a special kind of relationship, one we probably never saw. But that could lead to very nice and unexpected things I think.
Sure the community can contribute to wikidata, but wikidata itself is still centralized. The big social media websites have all of their content generated by their community, but no-one would consider them decentralized. By giving moderation control over funkwhale instances to the entity known as wikidata, that is centralizing the moderation of funkwhale instances.
I think it is okay to rely on musicbrainz, since its content is much less controversial being merely a catalogue of music, enables federation, and is not required in order to use the software. To my knowledge archive.org is only used for a downloader plugin, and the rest of your list is not used in the funkwhale codebase.
It's not that I don't trust wikidata, but I may disagree with the wikidata consensus on how to moderate my server. If I didn't care about the decentralised and federated nature of funkwhale, I would use something like a typical streaming service instead.
We already spoke about that
- But in this case, you as a maintainer are dictating that the wikidata community should control what my instance may listen to
Plz stop saying I'm dictating anything, this make me angry since I'm communication and being transparent so be respectfull with my opinions has I'm with yours... And don't answers that you meant "all the funkwhale maitainers" since again, this filter will not be maintained by us but by wikidata, by you or by anybody else.
- Well that is merely a redirection. The only difference between having the list hardcoded into funkwhale and having a wikidata query hardcodede is that it is easier to update the list with the query. It is similar to fetching the list over http instead of the local filesystem.
The difference is that the funkwhale maintainers are not the one building the list has you suggested by saying "The maintainers would control the list being hardcoded into funkwhale"
4 The current proposal is similar to DRM in my opinion. It punishes admins (like me) who would like to use the upstream funkwhale source, by deleting and filtering my instance's music using someone else's definition of nazi music. Meanwhile bad actors have several ways to get around it, and can fork the codebase to disable the filter and have a better experience. The moderation lists idea would give admins full control over the moderation of their instances, while still enabling the filtering of neo-nazi content. It would also enable more powerful filtering by allowing the use of multiple filter lists, rather than having to hard-code each list
yes we already spoke about that, don't want to repeat myself. Also you are saying we will add more lists in the future, which is not true. We are only speaking about far-right music content, nazi stuff. Not about other things.
New stuff
- Just because the wikidata community might come to a consensus, doesn't mean it is the singular truth. This is one of the reasons community governance of a decentralised, federated platform should not be centralized.
Yeah I agree, by definition consensus is not the singular truth. It's the compromise we've found collectively, most of the time finding compromises end-ups building more knowledge and tools. For example in the case of Burzum I suppose a compromise would be to create a distinction between nsbm artist and nsmb content. This would allows the creation of a new tag, and debates around which references can be used. Then the funkwhale community would have to choose how we update the filter. We would probably use the less constrained tag : meaning burzum will back on the funkwhale network. And on the road we would have build together tools against fascism.
So when you says that this moderation should be left to each community I ear that we shouldn't take the time to think together and build a common/international definition of neo nazi music. We should let each little community do its own work. It feels individualist.
- I think we can both agree that anti-sexism, anti-racism, anti-homophobia, et cetera are also not optional.
Yes ofc, and if an artist explicitly says a minority should be killed I think we can class them into the global class of neo-nazi music. But if it's only about vocabulary/about reproducing domination systems using social representations, it's more difficult since we use various definitions of words around the world. So finding a common ground is hard. But there is some of them we will all agree there are nazis, only these ones would be banned. That's why compromise is nice. It's flexible. And if it's not enough filtering for a community, then they can add other optional filters. I want to recall the list we are speaking about is super little, there is 60 artists top. So we're speaking of far-right content only, not about content that can offend people. Only content that promote the nazi ideology.
- Sure the community can contribute to wikidata, but wikidata itself is still centralized. The big social media websites have all of their content generated by their community, but no-one would consider them decentralized. By giving moderation control over funkwhale instances to the entity known as wikidata, that is centralizing the moderation of funkwhale instances.
This is not true. has already said you're creating a confusion between the technical and the institutional aspect of wikidata. Wikimedia foundation is non profit, anybody can comment and gain access to moderation privileges if following collectively build rules. It has nothing to do with gafam. It has nothing to do with a centralized moderation. Yes, the infra is centralized : meaning there is some specific threats to take into account. We can speak about these threats if you wish.
- I think it is okay to rely on musicbrainz, since its content is much less controversial being merely a catalogue of music, enables federation, and is not required in order to use the software. To my knowledge archive.org is only used for a downloader plugin, and the rest of your list is not used in the funkwhale codebase.
I don't think banning neo nazi music is controversial. Has you said, banning music that propagate discrimination by promoting some representation of the world is not cool, but it's very controversial and finding a common definition is very hard. But we are not speaking about that here. Here is the list of the tools we depend only for the api : https://dev.funkwhale.audio/funkwhale/funkwhale/-/blob/develop/api/poetry.lock?ref_type=heads.
- It's not that I don't trust wikidata, but I may disagree with the wikidata consensus on how to moderate my server. If I didn't care about the decentralised and federated nature of funkwhale, I would use something like a typical streaming service instead.
If you don't agree there will be no consensus. This is not changing the decentralized and federated dimension of Funkwhale. It's only adding one dependency in our code base, and another dependency in our political system. But we also rely on a lot of political stuff like the fact that were not responsible for the content that other people post on our software, or how other people use our software. We also can send our ip packets over the fibers cable without discrimination (network neutrality). All this is not community moderation, its collective fights, and I wish the decentralized aspect of Funkwhale do not make us forget that we are all in the same boat.
Edited by petitminionI feel compelled to voice my concerns here as well. To be clear, I am of the same opinion as @wieldable_animating626 - I don't have any association with Nazi music that I am aware of and certainly do not support it, but I think this hardcoded filter with no off switch is a bad idea and I will throw my support behind a fork if this actually goes through.
My opinion basically boils down to "I don't want anybody imposing arbitrary filters on my Funkwhale." Now, before you tell me that this isn't arbitrary, let me explain what I mean. First, by implementing this feature, you've set a precedent to create more filters in the future that meet your viewpoints. After all, once you start to compromise, there is no good place to stop; once you ban Nazi music, what's stopping you from banning Nazi-affiliated artists as well (see Burzum discussion), and then moving on to other music and artists you don't agree with?
You say:
I'm not dictating anything... There is nuance about if burzum is neo nazi content indeed. But burzum will not be banned from Funkwhale unless the wikidata community define it's neo-nazi
But this seems awfully much like dictation to me. In government, there is little difference between a sole dictator and a small group that dictates power; here, you're proposing to hand control of what music I can listen to to the Wikidata editors. I suspect there aren't that many people editing the Wikidata Nazi music list, so realistically they're now the small group dictating power.
This is not true. has already said you're creating a confusion between the technical and the institutional aspect of wikidata. Wikimedia foundation is non profit, anybody can comment and gain access to moderation privileges if following collectively build rules. It has nothing to do with gafam. It has nothing to do with a centralized moderation. Yes, the infra is centralized : meaning there is some specific threats to take into account. We can speak about these threats if you wish.
Being a nonprofit doesn't mean anything. Just look at OpenAI. Need I say more?
If you don't agree there will be no consensus.
What sort of argument is this? You are basically saying that I am not allowed to disagree with the current state of the Wikidata list because it would break consensus. The point of consensus is to consider all viewpoints and come to a common ground. By dismissing disagreements, you are breaking consensus, not preserving it.
Additionally, I am completely opposed to a hardcoded Wikidata filter, and yes, a Wikidata filter is still a hardcoded filter. In fact, I'd argue it's worse than just hardcoding a list in Funkwhale, because Wikidata is a third party over which you ultimately don't have any control. Yes, you can submit edits, but if the Wikidata admins decide they want to ban music on any topic, they can override any editors. To put this in perspective, you would never hardcode a URL to a shell script in Funkwhale (or any other) that you would just download and execute on the fly. Why? Somebody could hijack that remote script and make it malicious. Yet you propose to do basically the same thing with blocklists.
If you wanted Funkwhale to only rely on decentralised infrastructures it's already not the case we rely on : musicbrainz, archive.org, docker, nginx, gitlab,flarum,mailcow etc etc this list is infinite ^^
The difference is that those aren't being used to delete music from my library. This isn't about trusting third parties, it's about whether or not I want my software dictating what I can and cannot do.
Finally, I want to look at this statement:
This enforce your political views and beliefs on all other users
This enforce our collective Coc over all other users. If you don't agree to our CoC you should leave. We hope that all our user share our values against discrimination and fascism.
A code of conduct doesn't apply to an end user, it applies to people engaging with the project. Per your very own CoC:
This code of conduct applies both within community spaces and in other spaces involving the community. This includes the Funkwhale Matrix rooms, forums, issue tracker, blog and fediverse accounts and any other services provided to members of Funkwhale, or by members on behalf of the community, private email communications in the context of the community, and any events where members of the community are participating, as well as adjacent communities and venues affecting the community’s members.
My personal Funkwhale instance has zero ties to the Funkwhale community. Ergo, I am not beholden to your code of conduct. If you want to force antifascism on your users, you need to put that in your license, but that would make Funkwhale not free software. See the JSON license problem for a real-world example of how that would work.
I apologize if any of this came across as angry or attacking. It's not my intent to tear down but to build up.
First, by implementing this feature, you've set a precedent to create more filters in the future that meet your viewpoints. After all, once you start to compromise, there is no good place to stop; once you ban Nazi music, what's stopping you from banning Nazi-affiliated artists as well (see Burzum discussion), and then moving on to other music and artists you don't agree with?
this has been answered already : #2396 (comment 68968)
But this seems awfully much like dictation to me. In government, there is little difference between a sole dictator and a small group that dictates power; here, you're proposing to hand control of what music I can listen to to the Wikidata editors. I suspect there aren't that many people editing the Wikidata Nazi music list, so realistically they're now the small group dictating power.
If you have a artist you listen that is banned you can create an account on wikidata and change the artist genre tag accordingly. If it's legit it will be okey if it not there will be some debates.
Being a nonprofit doesn't mean anything. Just look at OpenAI. Need I say more?
be specific and plz use wikidata has an example to avoid incorrecte assoications
What sort of argument is this? You are basically saying that I am not allowed to disagree with the current state of the Wikidata list because it would break consensus. The point of consensus is to consider all viewpoints and come to a common ground. By dismissing disagreements, you are breaking consensus, not preserving it.
you didn't understood. If someone doesn't agrees there is no consensus. If there is no consensus the artist will not be tagged has neo nazi music.
Somebody could hijack that remote script and make it malicious. Yet you propose to do basically the same thing with blocklists.
Yes, you can submit edits, but if the Wikidata admins decide they want to ban music on any topic, they can override any editors.
give example of when this happened. It technically could. But we would only need to call other moderation to sort the situation. Also give example of when did this happened plz
The difference is that those aren't being used to delete music from my library. This isn't about trusting third parties, it's about whether or not I want my software dictating what I can and cannot do.
we are dictating what you can or cannot do each day choosing what feature to build and how we build them. If some lib break, if not maintainers do free work, you will have security issues, you will have feature going down. You accept that, why not accept to trust the people to build consistent neo nazi filter ? Why do you accept to trust people when they do free work and no when they do nazi filters ? ^^ Also yes I think we shouldn't allow nazi content to be spread on the network and you said you agree so the issue is not here.
My personal Funkwhale instance has zero ties to the Funkwhale community. Ergo, I am not beholden to your code of conduct. If you want to force antifascism on your users, you need to put that in your license, but that would make Funkwhale not free software. See the JSON license problem for a real-world example of how that would work.
It's an interesting idea to enforce this at a licence level. And yes our Coc doesn't apply to user outside of our spaces, I never said the opposite.
Edited by petitminion
Personaly I don't think we should change the licence but since it has been raise here is one examples :
Correct. You had said earlier that "This enforce our collective Coc over all other users. If you don't agree to our CoC you should leave." That sounded to me like you were saying "to use this software, you must abide by the CoC even if you aren't interacting with the Funkwhale community." But I see I must have been mistaken about that, sorry!
