FIRES allows for advisories against Fediverse actors, as well.
-
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
