Picking up from @bumblefudge
Following @jfinkhaeuser 's lead, I’d also like to get more practical here. (Sidenote just to @jfinkhaeuser : I can’t think of any FEPs relevant to the “identity-system gaps” which Jerry Bell explains in his linked post, but I do think someone with Matrix experience would be really relevant in the CG task force on moderation tooling, if you’re at liberty to do the IPR-release for CG work.)
Moderation, unfortunately, crosses technical and user interface realms. It’s clear enough that there isn’t a lot of fedi software with rich moderation interfaces, and I’d bet that “just” taking care of that would already improve things a lot. At least that is a complaint I read about a lot. As a result of this lack, admins organize organically and off fedi, which tends to create a bunch of in-groups, which may result in other social issues (TL;DR).
Looking at this from a purely technical perspective, there is at least one thing that keeps getting raised in various conversations for which a FEP would work: federation of block lists.
I’ll pick this one first, and then lead on to some others.
Blocklist Federation
- Block recommendations are usually simply notes describing the reason for the recommendation. They come in the instance vs. account block recommendation flavours.
- They are effectively already federated due to the above. What’s missing to make them actionable is to find machine consumable structure for them, i.e. a specialized Activity.
- Block recommendation Acitivities should likely contain copies of and references to receipts. That’s a slightly more complex topic than one can cover in a single post. I am reasonably certain this is going to be a hotly debated sub-topic
- Block recommendations I adopt should federate out from my instance as well, preferably with the original source intact (the path by which it reached me is probably less important, but see below).
- A caveat I find important is that generating block recommendation lists automatically from some specialized UI is one thing and probably safe. Consuming other folks’ block recommendation automatically, on the other hand, risks handing control over one’s social bubble to outsiders, in much the same way as centralized social media does. I would strongly recommend that the goal should be to ease administrators’ burden, not to cut them out of the process. Quite the contrary, they should stay in the process.
I don’t think it’d be too hard to come up with a FEP describing this in more detail.
Trust Management
A thing I keep repeating in various spaces is that a lot of computer models around trust are too coarse-grained, even binary at times. By contrast, fine-grained trust is a lot more transferable.
Say I trust admin X for their block recommendations when it comes to TERFs. They’re a bit blind on the side of black folk being targeted (whatever the reason). It’d be good to be able to issue a statement essentially encapsulating the first part: “I trust admin X’s recommendations on block reason Y”.
If I adopt a block recommendation, I might also add such a statement (in a separate Activity). Here, I may either select the original source of the recommendation or the source from which I imported it.
As a consumer of such trust statements, I can find UI choices to highlight more vs. less trusted block recommendations, both by myself and my own trusted peers.
Note that this should not lead to automation as per the last point above. But it is a system that helps ease administrative burden with appropriate transparency.
Standardization of Social Stuff
Two points emerge from the above:
- The explicitly mentioned “block reason”. It’s easier to deal with text programmatically that follows standardized forms. E.g. “nudity” vs. “NSFW” may mean different things. Though I write standardization here, the point isn’t to actually standardize these things. Rather, imagine we have data objects that contain such a keyword and a description, which we can reference. It’d allow admins to provide a content policy generated from such objects. It may similarly allow admins to adopt wording from such objects that others share. And one could reference those objects in trust statements and block recommendations. The goal would be to support the emergence of overlapping community standards, without veering towards enforcing a single “correct” interpretation of mores.
- Related to the above, a recommendation may not actually be to block specifically, but to e.g. limit an instance, or whatever the specific fedi software supports. First of all, it would be useful to provide context to the recommendation which immediately says little more than “I chose this option”. Second, a similar approach to the point above could be adopted, to help a common vocabulary of potential actions to emerge. Third, UI could permit for policies that translate from this vocabulary to actions the consuming software can actually take.
These objects in questions could be shared via specialized Activities. It may be risky to create copies of these, however, because an edit of the objects on one instance could lead to divergence from the wording on another instance, which then leads to more confusion than it may help.
Not that diverging definitions of a social concept such as “NSFW” are bad - but one needs unique and stable identifiers for each specific policy to have some kind of clarity.
These are not precisely to be taken as “I want to see all of this”. It’s more that I have been thinking about such systems for a while, and have come up with these three complementary approaches. My goals here are to:
- Not create a prescriptive system. Especially not to create a single prescriptive system with the expectation that it’ll apply equally to all.
- Be very opt-in. Not just as rephrasing the first point, but also to suggest that you do not have to opt in at all to this.
- Make space for individual admin choices, as well as for IFTAS-style organizations or other collaborations that might help set standards across instances.
I’m prone to thinking in systems, which has good and bad sides. I can imagine I’m getting some things very wrong here, though I try not to. I’d like to see what people, especially people with admin experience, think of this - and see if there’s a basis for evolving these ideas into FEPs.
