Thread refresh

things i would like to see in mastodon that pleroma has been able to do for years:

- the ability to defederate an instance except for *explicitly approved* accounts (pleroma has supported this since the beginning of MRF in 2018)

- the ability to defederate a hashtag (pleroma has supported this since 2019)

- the ability to quarantine unknown instances until they are approved by the admin (pleroma has supported this through a combination of multiple features since 2019)

@ariadne rejecting content based on hashtag has been on my list to do for Mastodon, but needs this activitypub issue resolved: https://github.com/w3c/activitypub/issues/424

This was an early attempt at this in Mastodon: https://github.com/mastodon/mastodon/pull/29264

Just silently dropping the message may not be the best option, hence needing community consensus on best practices

@thisismissem

This is interesting, but raises several questions for me (not that I'm anyone) that I've not seen addressed

Maybe early days in the larger issue, or something

Is this seen as content rejected because it contains $Word only, or content rejected because $Word is used in conjunction with a hashtag?

Who curates the list of $Words?

Then, a further question because of "Create a global default text filter to help prevent the use of racist and abusive language (Issue #31182)"

What language will the "global default text filter" list be kept in?

What becomes of other languages, which can be equally problematic on their own or in translation?

cc @ariadne

@FinchHaven @ariadne I think a lot of what's been said is based on the MRF capability, where (as I understand it) you run additional elixir code in your server, much like a plugin system.

MRF has been deemed dangerous by some because it allowed rewriting audience & text on posts & publishing Flag activities as Notes — i.e., you can use it to out people who report others & rewrite posts to make it look like someone has said something they haven't.

Basically, great power, great responsibility.

@thisismissem @FinchHaven nothing stops me from patching mastodon to do these things.

@ariadne @FinchHaven no, but it does create some barrier to misuse, which is arguably better than none.. it's all a balancing act.

@thisismissem @FinchHaven there is zero difference between someone publishing a patch to mastodon which does this and an MRF policy.

@ariadne @thisismissem @FinchHaven Also, respectfully: it's not even particularly difficult to patch Mastodon to do this! I'm not going to draw the rest of the owl, but it took me about five minutes to find the `process_audience` function and `visibility_from_audience` functions under `ActivityPub::Activity::[...]`; between that and patching `Status.create`, I'm pretty sure I could figure out a way to make all non-public statuses from a specific instance, user, etc. be public instead of private. And I wouldn't call myself a particularly proficient Ruby developer, either.

In my personal opinion, the harm that is currently being caused by not having flexible, extensible, and powerful moderation tooling *vastly* outweighs the harm that could be caused by making it easier for instance admins to do something that they're already able to do.

@andrew @thisismissem @FinchHaven yeah exactly.

sure, a moderation tooling framework can be abused to tamper with messages in a way that is anti-social. no doubt about it. moderation tooling has to be powerful in order to do its job.

but that reality does not justify the current *nothing* that mastodon developers are doing about anti-abuse since forever.

@ariadne @andrew @thisismissem @FinchHaven This smells like the chatter of ~25ya amongst email admins about whether content inspection was a step onto a slippery slope of admin abuses or whether it was unavoidable given spammer behavior.

I expect that eventually a similar outcome will result: better filtering giving admins excessive hypothetical power will become the norm, but only after the garbage gets really bad for everyone.

@FinchHaven @ariadne so when it comes to filtering instance wide, it ends up being "whatever your admin decides so you need to 100% trust them not to do bad things with the power they have.

I think for Mastodon, if I were to implement content filtering at instance level, I'd want a public log of actions related to be available to users on the server.

But the drop message versus said a rejection isn't yet worked out at ActivityPub level yet, afaik

@thisismissem @FinchHaven nothing about ActivityPub blocks anyone from adding a transparency log to MRF, or adding an MRF-like facility to Mastodon.

this is just absurd.

@thisismissem @FinchHaven like, respectfully, i think you all need to focus on why people like @KimCrayton1 are using Mastodon with basically *zero* mitigations to deal with trivial abuse instead of whether or not MRF is too powerful for your liking.

when Kim is no longer being crapflooded with racial slurs and threats, things that could be *trivially mitigated with MRF policies*, then maybe you can talk shit about MRF.

@thisismissem @FinchHaven @ariadne you can have MRF policies publicly listed and if an instance tampers more than they promise, it creates a (dis)reputation

also i might be wrong but i think public log of applied actions would be trivial compared to MRF itself

@xarvos @thisismissem @FinchHaven yes, precisely. it is a non-issue in practice with 6 years of MRF.