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

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

Also the new deltas API is going to be a game changer for sync.

cc @oli

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.

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.

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.

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

I guess I *could* add priority, allowing for a domain block except these actors

*hands you the first implementer badge*

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

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.

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

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.

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.