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

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