FIRES allows for advisories against Fediverse actors, as well.
-
"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.
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'.
-
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'.
For my linux nerds
curl -s -H 'Accept: application/ld+json' 'https://fires.1sland.social/datasets' | jqThe 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' | jqWhich also responds as text/html.
-
For my linux nerds
curl -s -H 'Accept: application/ld+json' 'https://fires.1sland.social/datasets' | jqThe 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' | jqWhich also responds as text/html.
@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.
-
https://archipelago.1sland.social/fires
FIRES - Home
FIRES: Fediverse Intelligence Replication Endpoint Server
(fires.1sland.social)
It's up and running, Pelago ingesting blocklists and creating FIRES advisories.
https://archipelago.1sland.social/blocklist/IFTAS%2DDNI
If you scroll down, you can see the entire FIRES snapshot and subscribe to the dataset.
As changes happen over time, you'll see retractions in the feed.
cc: @thisismissem
You can also see an example of 'filtering' on this page, if you scroll down. Rather than silence which can mean anything, there's a suggested list of filters to be applied.
https://archipelago.1sland.social/blocklist/IFTAS%2DAUD
Note that the existing labels were surfaced from IFTAS: Shared Vocabulary - Labels, along with the translations (when available).
The filters come from the FIRES project itself.
@oli nice work!
*hands you the first implementer badge*
-
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 'drop' 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.
-
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 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
-
@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%2DAUDAnd 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 -
For my linux nerds
curl -s -H 'Accept: application/ld+json' 'https://fires.1sland.social/datasets' | jqThe 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' | jqWhich also responds as text/html.
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 nice work!
*hands you the first implementer badge*
@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.
-
@thisismissem @oli @iftas if the issue is funding, I can help
-
@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%2DAUDAnd 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 -
@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.
@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 @oli @iftas if the issue is funding, I can help
@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@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.
-
@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 @oli @iftas @nlnet gotcha!
-
@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 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 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!)
-
R relay@relay.infosec.exchange shared this topic
