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)
- the ability to forcibly mark posts with content warnings based on keywords in their content (2018)
- the ability to forcibly mark media as sensitive based on keywords in the post's content (2018)
- the ability to reject media selectively based on various admin-configured signals (2018)
- the ability to derank remote posts based on their sentiment (not in pleroma mainline, but has been an active area of research in the MRF subsystem community since 2018)
- the ability to remove content warnings that are useless, e.g. from actors which constantly shitpost using content warnings (2018)
- the ability to require signups to complete a CAPTCHA to reduce instance abuse (2019) (edit: finally implemented in mastodon in 2023 and only because it became a problem on mastodon.social, which people started defederating)
- the ability to limit what instances get sent posts from a local actor (for example: to limit the possible damage caused by spicy posts) (2019)
- the ability to personalize representations of local posts when pushed or fetched by remote servers, e.g. to mold them into being consistent with that remote server's policy (2020)
look i'm just saying that the fediverse would be a better place if we had admin tools that were good
- moderation tools that are designed to be composed (e.g. used in concert with other moderation tools as part of a larger solution) (2018)
- automatically detect and mark explicit content as sensitive using perceptual hashing (2021)
- automatically reject illegal content using perceptual hashing (2021)
- block content using DNSBLs (2021)
- block incoming messages with excessive links (2019)
- block incoming messages with excessive mentions (2019)
- force bot traffic to post unlisted (2020)
- automatic mitigation of server-DoSing hellthreads (2018)
- automatic rejection of messages which reference unwanted remote emojis (2023)
- automatic follow spam blocking (2019)
- normalization of message HTML and mention/hashtag formatting (2019)
- normalization of inline mentions and hashtag presence (2019)
- filtering of activitystreams content types (2019)
i could keep going, but i think i've made my point
@ariadne A hearty "yes please" +1 to all of these; as an instance admin, I would use all of them π―
@ariadne i really hope #gotosocial @gotosocial devs are watching this
@ariadne do you know where I can find information on pleroma's perceptual hashing capabilities?
I've googled and looked through their source code but can't find anything yet, I did see there's a NSFW server, but couldn't find it's code..
@thisismissem itβs just photodna
@ariadne - ability to sing its name like the theme to Daytona USA
@ariadne what does this kind of personalization look like? Does it edit the content, or is it more on level of applying content warnings and alt text?
@ariadne CAPTCHA is already a thing. Just needs to be enabled.
@chad wow glad to see they finally caught up with pleroma in 2019 in this ONE area.
@ariadne at least the captcha thing is present in mainline mastodon
Are all these supported in akkoma as well?
@affine you can automate the allowlisting based on searching the object database for missing references
@ariadne honestly id move to *oma but like
there's literally like one somewhat good looking client for it, and it's soapbox
@halva there is a fork of soapbox done by some of the pleroma devs called mangane
This would be very handy to thwart disinformation used in scams, genocides, election interference, or climate denial.
@ariadne tbh, the openness of the MRF subsystem itself is worth a mention here. among the larger pleroma instances there's a culture of if you want some custom moderation feature, you can write a MRF policy yourself and just add it to your instance. I haven't seen anything like that among the mastodon instances (yes, there's patched codebases, but nothing intentionally made to be expandable)
@lillian yep that's because i designed it that way. you can't enumerate all possible threats, so you need a framework that can be extended by anyone.
@SpaceLifeForm @jerry @paco equally deficient
@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
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.
