Friendly reminder: last year I built FediMod FIRES, a protocol and reference server implementation for sharing moderation data.

I haven't yet been able to get anyone to adopt it or even signal intent to adopt. But regularly I see people complaining about the lack of data sharing when it comes to moderation, especially for combating spam, scams, and harassment. The tool is there, please use it!

Whilst I'm not actively working on FediMod FIRES this quarter, I did apply in November for a grant to continue that work, and last I heard a few weeks ago is that the grant made it to the next stage, so I may have some money again to fund development.

It's not 1.0.0 yet, because I decided it needed more work for me to be happy to call it that, but it is usable!

Installation is also super simple for data producers, literally two commands on debian or ubuntu boxes.

Learn more: https://fires.fedimod.org/manuals/reference-server/

#moderation #fediblock #administration

FIRES Reference Server | FediMod FIRES

Fediverse moderation Intelligence Replication Endpoint Server

FediMod FIRES
FIRES - Home

FIRES: Fediverse Intelligence Replication Endpoint Server

@thisismissem 404, btw.
@jay refetch the post, I made an update, I guess you didn't get it. Changed it to working links
@thisismissem
First time hearing about it tbh (and I don't admin large instances anyways πŸ˜…) but will take a look at it, sounds like it could be useful.
@the_moep yeah, it's been difficult to get the word out because I don't have a particularly large following.

@thisismissem I took a quick look at it and there are two things I'm wondering about:

  • Can this already integrate with Mastodon's FASP? If not, is that planed?
  • How are identities of moderated actors/instances as well as the moderating instances protected? As far as I can tell all of that information seems to be provided in clear text which imo would result in retaliation actions being taken against the people putting an instance on the list. Something like this has happened in the Minecraft community on global banlist projects and seems to be (in a lesser form) an issue with Bluesky's public blocklists as well. (And in the email-space Spamhaus gets attacked a lot as well)

@the_moep okay, a lot of questions!

1) FediMod FIRES is not related to Mastodon's FASP protocol. You shouldn't need an active connection to a FIRES server to process incoming activities.

2) Moderation data is shared publicly. Your server needs a copy of that data in order to take action. Moderation data providers can share as much or as little data about their operations as they desire.

3) The only way to not make the moderation data clear text would be by using Differential Privacy, and I absolutely do not have the cryptography knowledge to implement that.

4) Private datasets have been requested as a feature. Need to figure out access control. Existing datasets are all public.

Hope that helps.

@the_moep FediMod FIRES is more parallel to Bluesky's Labeler infrastructure rather than blocklists
@thisismissem probably not very helpful for now, but we intent to implement *lists (blocklists, email blocklists…) synchronisation in Mastodon in our next version.
We have not defined the exact scope yet but I want it to support FIRES (likely in addition to ingesting Β« simple Β» CSVs)

@thisismissem Who would be the target audience for FediMod FIRES? Is it anyone who moderates a fediverse server, or are you looking strictly for admins who can set up software integrations? Is there a minimum server size or moderation workload?

Is anything about it limited to Mastodon or is it applicable to all or most ActivityPub social platforms?

(🫒 Don't tell anyone, but I already know the answers to most of these, I just think it would be helpful to know for others reading this thread.)

@julian target audience is people producing moderation datasets, that's who'd run the servers.

The protocol can be consumed by any client then, which would likely be instance operators. It's generic not mastodon specific, it's a side protocol to ActivityPub, but uses similar concepts.

It could even be used with AT Protocol (though no one has tried that yet)

@thisismissem @jerry spreadin' the word, sounds very useful

@thisismissem you have pretty good installation tutorial but...not a single word about what to do after that

Or maybe I'm looking at wrong location, but I couldn't find anything about how to make up and running server do something useful (/nonneg)

Maybe I can help with documenting somehow?

@mo maybe, what are you looking for? UI screenshots? API docs? Happy to take contributions!

@thisismissem lets assume I, fedi admin, have a friend, who is also fedi admin, and we could benefit from exchanging moderation info, so questions which come to mind are..

- Do we need to run separate FIRES, or one single?
- If two, how do we make them exchange info?
- And, most importantly, how do we integrate it in our moderation workflows (so yes, API docs, if no native support yet)

Maybe it's somewhere in concept section, but IMO docs would be better with short overview from practical perspective

@mo you'd run a single FIRES server and both add information to it and then both of you would consume it.

@mo for "how to integrate it into our workflows", well, that's where we need platforms to adopt it, and make that possible.

There is technically a write API for some data, but I was told during development that a UI for managing the server was better than an API, so API was postponed.

@thisismissem native integration is the best, but with API power users can write glue scripts themselves, speeding up adoption
@mo that was why it was originally meant to be headless, and the feedback I received was that people had no idea how to use it if headless, so I had to make a choice UI or API as I didn't have funding for both β€” UI won last time.
@mo oh, also, my assumption was "post installation, you'll probably open your web browser to the server URL and start poking around and log in with the credentials you were shown"
@thisismissem well, there's not so much motivation to install something I don't understand how to use
@mo I'm also cautious to give screenshots right now because the plan is to completely revamp the admin next funding round
@mo FediMod FIRES as a reference server is also still pretty oriented towards early adopters, not mainstream market
@thisismissem
Is this essentially just blocklist sharing? Doesnt this introduce the potential for certain instances to censor users across multiple instances?

@trampinheavy that is a "risk" with all moderation data. Only use data providers you trust. If you don't have strong trust for their judgement, then you should be able to review manually, rather than apply automatically.

So yes, people can be blocked across multiple instances, entire instances can be blocked. That's nothing new, between existing CSV blocklists and the fediblock hashtag.

What this does differently is that it has both positive and negative signals: Accept this content, Filter this content, Reject/Drop this content.

It also encourages data providers to use labelling to add metadata to their blocks, so you can say "I trust IFTAS on CSAM but I don't want their recommendations on other topics.

And, most importantly: It supports retractions as a native part of the protocol: If someone or an instance is blocked, then they can become unblocked later; this is a lot harder to do with CSV files.

@thisismissem I am very interested in adopting this, for PieFed.

But when I look at the docs and every page says "This section of the documentation is still being written" it gives me pause.

@rimu yeah, I'm not the best docs writer, this was a huge effort! I would love to get collaborators to help advance it further. I definitely don't have all the answers
@rimu happy to jump on a call to discuss more
@thisismissem Is this intended to run along side your mastodon/gotosocial container? If so, we might be interested in adding it to our helm charts for deploying both.
@tootadmin yes-ish. The FediMod FIRES container image is the reference server for being a data producer; consumers need platforms to integrate or other tools to manage their integration (like what FediCheck did internally)
@thisismissem we would be interested, but we pay for hosting so not rly sure how that would work?
@Overgoddess depends on if you'd be a data producer or a data consumer (or both of course)