@thisismissem @julian On my side, some of the labels mapping to filters is irrelevant, since approving the labels on an advisory by promoting it to a recommendation for csam or other things is an auto-escalation to a reject policy. Not drop, straight up reject. And if you're recommending drop or reject, you don't need filters.

@thisismissem @julian// Label → recommended filters mapping. // When policy is "filter", the labels drive which specific filters to suggest. // See: https://fires.fedimod.org/concepts/filters.html variables.LABEL_FILTER_MAP = { "hate-speech" : ["auto-cw", "auto-unlisted", "auto-label", "prevent-trending", "reject-profile-avatars"], "dehumanisation" : ["auto-cw", "auto-unlisted", "auto-label", "prevent-trending", "reject-profile-avatars"], "online-harassment" : ["auto-unlisted", "prevent-trending", "reject-replies", "prevent-recommendations", "reject-non-public", "require-follow-requests"], "brigading" : ["auto-unlisted", "prevent-trending", "reject-replies", "prevent-recommendations", "reject-non-public", "require-follow-requests", "reject-reports"], "doxxing" : ["auto-unlisted", "prevent-trending", "reject-replies", "reject-non-public", "require-follow-requests"], "spam" : ["auto-unlisted", "prevent-trending", "prevent-recommendations", "reject-non-public", "require-follow-requests", "reject-replies", "roadblock-warn-links"], "farming" : ["auto-unlisted", "prevent-trending", "prevent-recommendations", "require-follow-requests", "reject-replies"], "service-abuse" : ["reject-media", "reject-reports", "prevent-trending", "reject-non-public", "reject-replies"], "disinformation" : ["auto-cw", "auto-label", "prevent-trending", "prevent-recommendations", "roadblock-warn-links"], "misinformation" : ["auto-cw", "auto-label", "prevent-trending", "roadblock-warn-links"], "explicit-content" : ["auto-sensitive", "auto-cw", "age-restrict", "prevent-trending", "reject-profile-media"], "phishing" : ["roadblock-disable-links", "prevent-trending", "prevent-recommendations", "reject-non-public", "require-follow-requests", "reject-replies"], "impersonation" : ["auto-label", "prevent-trending", "prevent-recommendations", "reject-profile-media", "require-follow-requests", "reject-replies"], "troll" : ["auto-unlisted", "prevent-trending", "reject-replies", "prevent-recommendations", "reject-non-public", "require-follow-requests"], "incitement" : ["auto-cw", "auto-unlisted", "prevent-trending", "reject-replies"], "glorification-of-violence": ["auto-cw", "auto-sensitive", "auto-unlisted", "prevent-trending", "age-restrict"], "violent-threat" : ["auto-cw", "auto-unlisted", "prevent-trending", "reject-replies", "reject-non-public"], "defamation" : ["auto-cw", "auto-label", "prevent-trending"], "sextortion" : ["auto-unlisted", "prevent-trending", "reject-replies", "reject-non-public", "require-follow-requests", "roadblock-disable-links"], "catfishing" : ["auto-label", "prevent-trending", "prevent-recommendations", "reject-profile-media", "require-follow-requests", "reject-replies"], "astroturfing" : ["auto-label", "prevent-trending", "prevent-recommendations", "reject-replies"], "cib" : ["auto-label", "prevent-trending", "prevent-recommendations", "reject-reports", "reject-replies"], "sock-puppet" : ["auto-label", "prevent-trending", "prevent-recommendations", "reject-replies"], "cross-platform-abuse" : ["auto-unlisted", "prevent-trending", "reject-replies", "reject-non-public", "require-follow-requests"], "synthetic-media" : ["auto-cw", "auto-label", "auto-sensitive", "prevent-trending", "reject-media"], "copyright-infringement" : ["auto-unlisted", "prevent-trending", "reject-media"], "counterfeit" : ["auto-unlisted", "roadblock-warn-links", "prevent-trending", "roadblock-disable-links"], "account-takeover" : ["prevent-trending", "prevent-recommendations", "reject-non-public", "require-follow-requests"], "apt" : ["reject-media", "roadblock-disable-links", "prevent-trending", "reject-non-public", "reject-reports", "reject-replies"], "csam" : ["reject-media", "reject-profile-media", "auto-sensitive", "age-restrict", "prevent-trending", "prevent-recommendations", "reject-non-public", "require-follow-requests"], "csea" : ["reject-media", "reject-profile-media", "auto-sensitive", "age-restrict", "prevent-trending", "prevent-recommendations", "reject-non-public", "require-follow-requests"], "ncii" : ["reject-media", "reject-profile-media", "auto-sensitive", "age-restrict", "prevent-trending", "prevent-recommendations", "reject-non-public", "require-follow-requests"], "tvec" : ["reject-media", "auto-cw", "auto-sensitive", "prevent-trending", "prevent-recommendations", "reject-replies", "reject-non-public", "roadblock-disable-links"], "content-and-conduct-related-risk" : ["auto-cw", "prevent-trending"],

	// Pelago-specific labels
	"suicide-baiting"    : ["auto-cw", "auto-unlisted", "prevent-trending", "reject-replies", "reject-non-public", "require-follow-requests"],
	"antiblackness"      : ["auto-cw", "auto-unlisted", "auto-label", "prevent-trending", "reject-profile-avatars"],
	"queerphobia"        : ["auto-cw", "auto-unlisted", "auto-label", "prevent-trending", "reject-profile-avatars"],
	"block-evasion"      : ["auto-unlisted", "prevent-trending", "reject-replies", "reject-non-public", "require-follow-requests", "prevent-recommendations"],
	"lax-moderation"     : ["prevent-trending", "prevent-recommendations", "require-follow-requests"]

Just as a starting point.

@thisismissem @julianFor myself:reject and drop are suspendfilter is silence on a blocklist, I guess but there are literally filters for reject-media and reject-reports, which also show up on blocklists, if you translate feeds. There's also things like 'require follow requests'...check out https://fires.1sland.social and especially the FreeDNS dataset for a lot of drops followed by a lot of retractions. It's got 25000 things on it and is a good stress test, as every so often it's checking freedns to see what domains are available (and thus risky). They come on and off the list all the time. It's recommending suspend/drop at this point, but filter is a better suggestion for something as preventative as 'someone might use one of these disposable domains to do something bad'. If your filters are strong enough to actually do the things they say they'll do, then you'll get very nuanced information back.In the case of Pelago as a data producer, certain labels indicate certain filter suggestions.I'll break that all down later. But in the end I've decided to refactor Pelago to be a native FIRES server, and implement the spec itself as well.FreeDNS is a great example of something where you get the snapshot once and cursor over the changes rather than drinking the ocean every time.A dataset for "Open Registration (No Manual Review)" is coming soon, too. That'll be fun. It will be filters only, but the filters will be the usual.Oh, I'm implementing all the filters shown here, with the identifiers as shown, except the last one which is for email domains:https://fires.fedimod.org/concepts/filters.html

@julian writing all the docs takes a huge amount of time 😅I also don't think I've structured them right yet

@thisismissem@hachyderm.io hah okay, I'll take notes on omissions I find as well.

@julian I was informed of one gap in the documentation but the API is very follow your nose

@thisismissem@hachyderm.io great, I'm good to implement those. I'll have to take a closer look at the FIRES documentation next week 🙂

@julian so suspend is either reject or drop as a recommendation; reject say you should tell the sending server "I reject this activity" drop is "I acknowledge this activity but it quietly goes to /dev/null

@thisismissem@hachyderm.io any specific place you want feedback (officially)?

I have no desire for anything more than those 3.

@julian waiting for implementations to give me feedback

@thisismissem@hachyderm.io have you settled on a list I can code against? iirc we had discussed suspend, filter, and allow. Not sure if the terms have changed since.

@julian yeah, we don't currently support a "silence" because no one really knows what that means so we're pushing towards more granular filters

@thisismissem@hachyderm.io hashtag filtering would be handy. I'm interested in seeing how that will shape up. Apologies for missing the T&S call yesterday.

I noted in my third-party blocklist implementation that IFTAS DNI and AUD lists classify entries as silence or suspend. I am assuming that these are expanded in FIRES with a couple additional items?

I may be mis-remembering from our talk a couple months back :smile:

@julian You'll definitely want a FederationPolicies model, beyond just a "block these domains" list.For instance, coming in the future to FIRES is a way to distribute Hashtags that may contain harmful content, such that you could choose to filter those out.Or, maybe you want to filter those in (I see you NodeBB and how you get content federated in!)

@thisismissem@hachyderm.io yeah we did, although at the time I hadn't properly implemented anything except a text box for domains to block or allow.

Now it can pull a blocklist by URL, but no support for more than suspend at the moment.

@julian we've definitely talked about how to implement!Also the new deltas API is going to be a game changer for sync.cc @oli

@oli you can also publish multiple entity types on one list, so you could have separate rules for a domain and some of its actors.I guess I could add priority, allowing for a domain block except these actors

I'm working on a PR for this in Fediblockhole, too. It supports many formats, and talking to FIRES gives it state management for retractions it's never really had before--I mean, there's an explicit 'Retraction' type.

@oli@olifant.social abso-bloody-lutely love this.

NodeBB just added in support for third party blocklists, with the IFTAS DNI and AUD lists as default.

It would be great to support FIRES endpoints as well.

@thisismissem

For my linux nerds curl -s -H 'Accept: application/ld+json' 'https://fires.1sland.social/datasets' | jq .... FIRES does content negotiation, so hit https://fires.1sland.social/datasets in your web browser and hit it with a proper JSON header and you'll get different results.There's also a curl -s -H 'Accept: application/ld+json' 'https://fires.1sland.social/labels' | jq and associated https://fires.1sland.social/labels for your scripting enjoyments.

Every night the blocklists are updated, and now when that happens we'll also add new recommendations or retractions to the FIRES dataset as well, automatically. Pelago and FIRES are essentially married in my implementation now, able to pass some FIRES configuration to a Pelago instance, prefilling the IFTAS labels and seeding the data from configured/enabled blocklists.Of course we can add other labels and stuff eventually, but I felt like IFTAS did a good job covering most of the bases rather than creating non-standard labels like 'edgelord' and 'fuckface'.

"But I don't like that blocklist project!"That's why you completely ignore that dataset, then. Pick the dataset you trust and go from there. Eventually datasets will be created by more than just blocklists. They'll be organic community contributions, perhaps, authored by a council directly on the FIRES server--that can be a whole other dataset.In the meantime, we've got a protocol for syncing moderation advisories, y'all. Just need the consuming software (ie., Mastodon, GTS, Akkoma, etc) to start ingesting it.

This is also how GoToSocial could take a filter advisory to disallow replies from an entire server or from specific accounts.In fact, the Domain Limits, interaction control and (eventually) canQuote logic all fit into the filter advisories, and I suspect with an existing Domain Subscriptions model, connecting to a FIRES dataset or /changes endpoint is going to be possible, just needs to get on the roadmap.

FIRES allows for advisories against Fediverse actors, as well.This is very, very similar to 'composeable moderation'. You subscribe to a dataset, and you can either grab the latest snapshot or subscribe and pull changes over time, so a retractions come in you can have things pulled off your blocklist.It also adds a bit more nuance. Things start out as advisories and can escalate to recommendations, but even a recommendation of 'block' doesn't mean autoblock, it's supposed to be a suggestion to your software (Mastodon, etc) to give you an option or to allow you to auto-accept. You might not care about things tagged with a label of 'Spam' so you let those through, for instance.This is essentially the protocol the Fediverse has needed to allow for sharing nuanced moderation recommendations. All you need to do is find a dataset or datasets you want to subscribe to, and can pull in those changes.This is all based on the work done by Em, the FIRES server I'm hosting is her reference server implementation, I'm just sideloading it from Pelago.Everyone is free to use my fires.1sland.social server as a real FIRES server for development purposes, in terms of testing the protocol.No retractions yet, but those will show up over time.

@GroupNebula563 It's going to be like whack-a-mole, isn't it... UGH @atlas_autonomous@piaille.fr