|
Top-level
 FIRES outlines a few different things, one of those being a different model of federation management, not centered on binary decisions of "blocking or not", but instead a more firewall based approach: allow / filter / reject. FIRES is also not focused exclusively on domain based federation management, but looks at issues that will become more pertinent as the Fediverse grows, for instance Hashtag or Link management. 6 comments
Finally, FIRES makes zero opinions on how data enters the system: whether it's through a collective voting on taking specific action, or an algorithmic sourcing of data, this is up to upstream software to decide, FIRES will just keep a record of those decisions over time. Within scope of funding may be building some of these tools, that's still to be decided. I look forwards to working with NLNet to help bring distributed moderation data to the Fediverse. Just to be absolutely clear: I'm not entering the business of curating a blocklist, I'm writing the software to help distribute moderation recommendations and advisories.  @polotek for this month, I'm mostly needing financial backing (since I've been unwell & my billable hours are down significantly) The reference implementation of the FIRES server will be written in Node.js though, so once I start building it out perhaps there's room to bring on paid collaborators? (I need NLNet's approval for this, afaik) https://support.thisismissem.social (one-time at bottom, addresses only used for invoices) |
Gregory's Server
Another idea it puts forwards is the use of structured data for labeling decisions, for instance, maybe you trust a providers' recommendations related to racism but not transphobia, or maybe you want the CSAM and DNI data, but not to block bridges. This is all possible if we've more structured data.