Integration and collaboration

[nemobis]

Thanks for your presentation at FOSDEM. Here are some questions I didn't manage to ask. :)

1. Have you looked into other FLOSS systems like MediaWiki AbuseFilter and Wikimedia ORES?
2. Is there any open data (CC-0) dataset that can be imported or otherwise used in osprey to kickstart an instance?
3. Are there import/export facilities or other ways for friendly instances to share data with each other, e.g. for scoring purposes? Perhaps in a federated matter? A simple example being some of the fediverse shared blocklists?
4. Does osprey have facilities to help online services with complying with the Digital Services Act art. 17 requirements for information and redress mechanisms to be provided to the people hit by moderation actions?

[julietshen]

Hello and sorry for the late reply!

1. We have looked into those systems, especially during the research the ROOST team did while incubating (some findings are in the paper on T&S tools ). Both AbuseFilter and Osprey are fundamentally rules engines for evaluating events and taking automated actions, but Osprey is more generalized since AbuseFilter was purpose-built for Wiki events and variables. Theoretically it could be used together where MediaWiki emits events via hooks or change propagation streams, Osprey ingests them, evaluates rules, and returns verdicts that MediaWiki acts on.

ORES is a big more interesting because it can be one of the signals that goes into Osprey. I can see it being like: ORES produces probability scores; Osprey consumes signals and evaluates them against rules. You could configure Osprey rules like "if ORES damaging score > 0.85 AND user account age < 24 hours, then auto-revert and flag for review."

2. Since Osprey is designed for streamed events, a dataset might not help kickstart it...but we do know there needs to be more complex demo data. I have some local changes working on synthetic batched data that can be used for trying Osprey out!

3. The short answer is: not yet as a built-in feature (you're welcome to propose it in a working group meeting or here!), but the architecture has natural extension points for this, and it's something we're thinking about. Osprey supports external signal lookups via UDFs and a UDF can call out to any external service (like a shared blocklist if that's what you want) and use the result in rule evaluation. If a shared blocklist or scoring service existed as an API, an Osprey deployment could consume it as a signal source alongside its own local rules. I'm mindful that different instances might have different norms and rules. Someone from the Fediverse could also build some features that allow for either signal-sharing or action-sharing so every instance can make their own decision.

4. similarly to 3, the architecture supports this where you can configure a rule to apply an action and that action might have a label that is attached to some email/notification service that communicates a moderation action to a user. But TBH Coop (our other project) is probably better since it's designed for a lot of those workflows. It's a manual review tool that also supports automated actions, supports appeals and appeal reviews, and also has a nice audit log for decisions made.

LMK if you have any other questions or thoughts!

[nemobis]

Thanks, I had missed Coop and the paper. Some great ideas in here!