NodeBB

@oli @julian yeah, so I'm interested in what filters applications need, and a good future feature will be "filtersets" which don't affect the public API but do change the admin experience (e.g., you could create a "silence" filter that includes these named filters, so you can apply them all at once repeatedly, but to a consumer it's still clear you're recommending they take these specific actions

And remember: the datasets only contain recommendations, they're not prescriptive. Any consumer can decide to ignore your recommendations as a dataset producer and do something different.

@julian writing all the docs takes a huge amount of time

I also don't think I've structured them right yet

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

@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

@julian we have four policies: Accept, Filter, Reject, Drop

We have N filters: https://fires.fedimod.org/concepts/filters.html

@julian waiting for implementations to give me feedback

@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

@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!)

@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

@ricci @oli @iftas for IFTAS, they wanted some features I couldn't deliver within the timeframe of my grant, and right now I'm busy with client work. I do have a new grant proposal submitted to @nlnet and last I heard it was approved for next round. I don't think I'll have the grant MoU signed before June at the earliest.

So it wasn't a funding issue on IFTAS's side particularly — FIRES isn't a particularly demanding application to run & can be cached heavily.

@oli oh! The datasets need to be absolute URIs, as their @id's like in activitypub — the path isn't part of the protocol, just the absolute URI

@oli @iftas yeah, I was trying to get Jaz to become FIRES native, and we'd upload the full historical snapshot of those deny lists that we have.

That's what powered the test data you saw & how I built the CSV import feature. I still have no idea how to give a REST API for that for programmatic use.

@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

@oli i have historical CSVs for IFTAS if you want them (though I'm still trying to get @iftas to deploy a FIRES server (I'd manage it for them)

@oli nice work!

*hands you the first implementer badge*