 ActivityPub Filter System Inspired by Pleroma (MRF) and Cloudflare (WAF), this new @pixelfed feature will help improve safety and moderation by empowering admins with fine-grained tools like these. Better yet, you will be able to easily import/export rules and I'm working on a FEP so other projects can add support using a common vocab. Available soon β¨ 12 comments
 E.g., a system like this if used to, say, detect slurs, wouldn't really understand reclaimed slurs or vernacular context, so could actually add harm or restrictions to marginalised users speech or reach. @thisismissem @pixelfed I agree, I'm not sure this is the best approach in that case, but it could be useful in cases where spam domains are used. Perhaps we could discuss on Matrix or Discord further? I'd probably go with building a feature specifically designed for mitigating spam or malicious URLs, over a more generalised system for something like that. Especially because those rules / actions might need to be taken in some sort of adaptive approach. But still, being able to preview and see what the filter catches or doesn't is still important.  @thisismissem @dansup @pixelfed It's not a great idea on it's own.. more of a defense in depth thing but I'd imagine we could have a risk score with metadata {score: 5, keywords:abusive:3, trigger: norelationship:2} @thisismissem @dansup @pixelfed I could think of a bunch of risks trigger:limitedinstance:2 etc etc.... having one risk isn't enough to push it over the edge to a filter. edit: if 5 is a threshold (people can move it up/down as required per account) but receiving a toot with a slur from a friend on a non-limited instance would be fine... so mutuals can swear away The more data that you want to provide the decision making process, the more expensive it becomes to execute, and the more likely you are to need to maintain some form of state. e.g., rolling windows for types of activities, that's a whole bunch of state that needs to be stored temporarily. That is to say, the more data to evaluate & more state to consider/store, the slower the rules become to execute, potentially requiring asynchronous instead of synchronous processing @thisismissem @dansup @pixelfed id say a lot of this can be done retroactively as well @thisismissem @pixelfed Yeah, that is a valid concern, the approach I'm taking is to efficiently cache the rules and invoke them early in the request lifecycle. The sooner we can invalidate activities in the inbox req lifecycle, the better IMO
[DATA EXPUNGED]
|
Gregory's Server
@dansup @pixelfed
I would be pretty surprised if this didn't come with some significant performance issues (probably somewhat fixable) β also wondering if you've looked at something like SQRL language & runtime?
You'll also likely want a warning about the scunthorpe problem & to just move matching activities to a manual approval queue (rather than dropping completely)