Federation Policies and limit/suspend/etc.?

Hi @thisismissem, apologies if this has been asked previously.

I noticed upon looking at the IFTAS blocklists that #severity is either silence or suspend. My feeling is that this aligns with Mastodon's usages, since they adopted the format Mastodon uses for shared blocklists.

Has the T&S TF put together a recommended list of levels for federation policies, and if so, do they align with what FIRES would also publish?

This doc article notes that the levels are Reject media, limit, suspend, and blocklist, with "silence" being the former name of "limit".

Right now NodeBB does a binary "if you're on the list everything is blocked" approach, but I'm looking to add some granularity.

Thanks!

Oh, I remember now we've had scattered discussions about this. I even did a slide about it at FediCon last August.

We had identified four levels:

• Allow
• Filter (further processing required: manual review, sentiment analysis, spam filtering)
• Deny/Reject (explicit rejection)
• Drop (quiet rejection)

Has T&S updated this list since?

That's basically it. T&S hasn't currently been working on this specifically, because we're probably needing adopters to define what exactly filtering does. Right now I've just proposed some ideas of what it could do.

I do believe "silence" is a group of filter operations.

The way to look at this is to look at the features that your application has to determine what filters make sense. Some will be common across all activitypub apps, others will be specific to your given vertical and how you app works. (It's essentially threat modelling for moderation/trust & safety)

@thisismissem Yes, that's exactly where I'm at now.

I'm looking at that list of four and finding only three that apply. I am adding in the ability to push incoming AP objects into NodeBB's post queue, so that's filter.

We just don't really have a need to quietly reject something vs. explicitly rejecting it.