FIRES allows for advisories against Fediverse actors, as well.

[oli@olifant.social]

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.

[oli@olifant.social]

"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.

[oli@olifant.social]

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 (albeit delightful) labels like 'edgelord' and 'fuckface'.

[oli@olifant.social]

For my linux nerds

curl -s -H 'Accept: application/ld+json' 'https://fires.1sland.social/datasets' | jq

The FIRES reference server does content negotiation, so hit https://fires.1sland.social/datasets in your web browser, and then hit it with a proper JSON header and you'll see different results.

There's also a labels endpoint:

curl -s -H 'Accept: application/ld+json' 'https://fires.1sland.social/labels' | jq

Which also responds as text/html.

[julian@activitypub.space]

@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

[thisismissem@hachyderm.io]

@oli nice work!

*hands you the first implementer badge*

[thisismissem@hachyderm.io]

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

[thisismissem@hachyderm.io]

@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@olifant.social]

@thisismissem @iftas They are regularly updating their CSVs, I thought. I've been pulling updates:

https://archipelago.1sland.social/blocklist/IFTAS%2DDNI
https://archipelago.1sland.social/blocklist/IFTAS%2DAUD

And that means they now have a regularly updated dataset for it now, too:

https://fires.1sland.social/datasets/iftas-abandoned-and-unmanaged-denylist
https://fires.1sland.social/datasets/iftas-do-not-interact

[oli@olifant.social]

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]

@thisismissem It's been a lot of fun. My next trick is to tie this into Fediblockhole so that FIRES just becomes another source you can pull in data from to build lists or push blocks to your server if you so choose--while also allowing Retractions to literally pull blocks off your server with it, adding a statefulness we didn't have before in Fediblockhole. Which I imagine is still a pretty common way to pull blocks, but imagine a Fediblockhole config like this:

blocklist_fires_sources = [
  # { server = 'https://fires.1sland.social' },  # all datasets on this server
  { server = 'https://fires.1sland.social', datasets = [
    '019d36a7-fb61-7d3d-9228-b0e658f7ef0c', # Oliphant Ad Hoc Fediblock list
    '019d36a7-3274-77a4-8ee9-9f26dd2faa4f', # Seirdy's FediNuke
    '019d36a7-f621-7842-a00b-35cc2fecc8d7', # Gardenfence
    # '019d36a8-024f-7f44-855f-dfdf5badf536', # The Bad Space 90% Consensus
    # '019d36a7-34e0-7515-9990-58196d3ab9eb', # FreeDNS (25k domains, very large!)
    '019d36a7-f91a-7837-aeea-fb2ae48b67fe', # IFTAS AUD
    '019d36a7-f9a1-7546-8dd8-e88b14834cdf' # IFTAS DNI
    ], retractions = true },
  { url = 'http://localhost:4444/datasets/019d37ae-8f62-74ec-95f5-92ce0dba4ea4', retractions = true },
  # { url = 'https://other-fires.example/datasets/019d3565-f022-777b-abbc-aabbccddeeff', max_severity = 'silence' },
  # { server = 'https://fires.example.com', ignore_accept = true },  # ignore 'accept' policies
  # { server = 'https://fires.example.com', retractions = true },  # honor retractions from this source
  # { url = 'https://trusted-fires.example/datasets/uuid', retractions = true },
]

You did nice work.

[ricci@discuss.systems]

@thisismissem @oli @iftas if the issue is funding, I can help

[thisismissem@hachyderm.io]

@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.

[thisismissem@hachyderm.io]

@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

[thisismissem@hachyderm.io]

@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.

[thisismissem@hachyderm.io]

@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@discuss.systems]

@thisismissem @oli @iftas @nlnet gotcha!

[julian@activitypub.space]

@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.

[thisismissem@hachyderm.io]

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