After 8 months working on Mastodon, in particular on infrastructure for mastodon.social and mastodon.online, I have been able to articulate my vision for the future of Trust & Safery for Mastodon : https://renchap.com/blog/post/evolving_mastodon_trust_and_safety/
We need better tools to go along the growth of the Fediverse, and they need to enable multiple instances to work together on those topics and keep our loved network safe for everyone!
@renchap Thanks for the writeup, and it's great to hear that Mastodon gGmbH has heard that the community is asking for more effort in this area.
As things move forward, it's critical to get the input of people communities who are targeted by hate speech and most at risk from harassment -- including women, BIPOC, trans and non-binary people, Muslims, Dalits, disabled people, and especially people at the intersections. They're the experts, but their input is often ignored -- Twitter for example repeatedly rolled out moderation solutions they thought would help but had obvious holes, and Bluesky's making the same mistake. So this is a chance for the fediverse to do better -- while also making progress on some of its equity issues.
@renchap At this point, I wonder if we could learn from the Amish (or Simon Sinek's "Leaders eat last") and maybe limit the size of instances to 150-250 members, making the content-aspect manageable by one human with no advanced-tech background, and maybe have one "shaman" for the tech-aspects of several "villages", as maintaining seems to me easier than installing.
@nemobis I am not an expert in these topics, and I hope people with more experience than me (and who read the existing research) will join forces to make this happen in the best way possible.
This is my personal point of view on the topic, and I hope it will kickstart some work around it. I always welcome feedback and suggestions!
That would be useful even if the initial version is focused on Mastodon. (You never know, maybe the developers of some other apps will come along and adopt the idea.)
An advantage is that people could add links, there would be a wiki-like document with the latest thinking, there's already a forum where to gather comments etc.
@renchap Along that same line, the tools need to play well with each other. I hope that we don't see projects like Akkoma and Calckey as competition but variation and all working together to achieve the same goal - kicking corporate out of social media.
@housepanther@renchap One of the top perks of separating the moderation tools out from Mastodon itself would be that other fediverse software could use those same tools.
One of those immediate lessons from the Lemmy/Kbin spike was that fediverse moderation tools are very, very unequally available to different platforms.
@renchap sounds like you want to have moderation turned into a service and provide the ability to integrate several of these services into an instance with rules and controls for how they are fed/consumed and the level of action that their response will incur. As long as trust and transparency is marched forward in lockstep with scalability, I think this could be a solid approach.
@renchap I like these thoughts on the future of moderation / safety. I can anticipate the same people who dislike shared blocklists saying "centralization", but I see it as decoupling and modularization, only giving more options to people. This could even increase decentralization by enabling more people to selfhost without being forced to do their own moderation.
@antifawarlord I 100% agree :)
I like decentralisation, but I also know first hand what the limits are, and what challenges we are (and will be) facing.
Also decentralisation is not isolation, something many forget.
@antifawarlord@renchap @tchambers
There seems to be an evolutionary option to create curated blocking lists with different levels of strictness on different problem areas. An enhanced block list “bank” could potentially be a seed of a solution.
Each block list is based upon a particular group of problems allowing admins to supplement their block lists based upon their policies and provide feedback into the block list bank.
The admins who administer a particular policy could curate the list with their policy and contribute it to a blocklist bank that can be hosted and replicated (think rsync) to anyone who wants to use it.
2/2
@schmubba@antifawarlord@renchap@tchambers I find the entire idea of blocklists extremely problematic. Unless there is a clearly defined policy of why an instance gets added to a blocklist and a process of review that's transparent there will always be the opportunity to weaponize a block list. Automating the distribution of the block list exacerbates the problem 10 fold.
@mike@antifawarlord@renchap@tchambers
I see the irony.
It would really be fact sharing about who you blocked and why on your instance in a structured way so other admins could make intelligent decisions about their instance. More of a bad actor sharing rather than a system wide ban list (which I think exists now).
nearly any social media affordance can we weaponized for good or ill. they're extremely useful for efficiently blocking fascists, racists, misogynists, transphobes, etc. the fact that a fascist can create a blocklist for progressives doesn't bother me - they have been out-organizing the left for years - it's about time we used some of those techniques.
@crumbleneedy@schmubba@antifawarlord@renchap@tchambers I'd prefer to take on that responsibility rather than delegate it to unknown entities no matter how well intentioned. Our tools for moderation and the autonomy of instances are what set us apart, trying to reconsolidate these powers centrally is the philosophy that drove most of us here in the first place.
@mike@schmubba@antifawarlord@renchap@tchambers my experience with blocklists on twitter is that someone makes one and shares it, and it's up to the individual as to whether they use it (and modify it) or not. not sure about other use cases.
@crumbleneedy@schmubba@antifawarlord@renchap@tchambers I was speaking more to admins and block lists of instances. Whatever the user wants to do at their level is completely up to them. Another great feature of the fediverse
@FinchHaven I dont know about AT/BlueSky (and not really interested in it), but my proposal is not about having moderation being implemented by algorithms, nor off-loading it to enterprises.
I thought is was clear from my article.
"I envision the implementation in Mastodon’s software to be mostly around a few areas"
"Most of what I discussed above could probably be implemented with the existing Mastodon API & Webhook, but I strongly think we need to work on a specific protocol for this purpose"
"protocol would be based on HTTP, versioned, and would use simple and common interfaces such as a REST API and Webhooks..."
If this does not involve algorithms, how is it manifested?
@renchap glad to see i'm not the only one who thinks it needs more webhooks (i'm the person who added status.created, status.updated, and account.updated)
@vyr I am not sure the status webhooks are a good idea, they lack the granularity and control over data that I envision. They are good in the short/medium term, but we need something more complex that those privacy-wise, but this can be achieved with what I described :)
@renchap being able to create one-off webhooks with more granular permissions and property filtering seems like the way to go, especially given connecting third parties directly is now a possibility
Add comment