It is depressing if someone experiences hate on here, especially if it puts them off using this place.
I follow people that regularly raise these issues, to hear how bad it is and what the causes are.
Five things seem to come up most often:
- Lack of representation in software design
- Users not being able to control who can reply to their posts
- Moderation being reactive rather than proactive
- Allowlists vs blocklists
- Cultural problems
Let's look closer...
🧵 Thread - Part 1 of 7
- Lack of representation in software design.
Most FOSS is made by whoever is able to spare unpaid work and has the right tech skills to build it.
This often leaves FOSS devs under-resourced and thankless, rationing their time to deal with an avalanche of reported issues, prioritising what to fix with very limited resources.
If there was better representation of vulnerable groups in FOSS development and prioritisation, it might lead to better safety tools in software.
🧵 Thread - Part 2 of 7
@FediTips I've been quietly ranting along similar lines for awhile now: Software Uprising
- Users not being able to control who can reply to their posts
The Fediverse having thousands of independent servers is one of its greatest strengths (https://fedi.tips/why-is-the-fediverse-on-so-many-separate-servers) but also causes whack-a-mole problems when trying to block hate.
If users could pre-emptively restrict who can reply to their post, e.g. followers-only, this would prevent hatemongers from random unblocked servers posting nasty replies.
Github users can vote for this at https://github.com/mastodon/mastodon/issues/14762
🧵 Thread - Part 3 of 7
@FediTips Re: reply controls.
GoToSocial came up with a way (https://docs.gotosocial.org/en/latest/federation/interaction_controls/) to do this. It doesn't “solve” malicious servers, but it lets benevolent servers honor each other's inhabitants' wishes.
I'm drafting a “Fediverse Enhancement Proposal” document to make it easier for other projects to join GTS. It's progressing, but I have day job stuff etc. It might help to add a few collaborators.
Anyone comfortable w/ technical specs similar to this https://fediverse.codeberg.page/fep/fep/044f/ & want to help?
This is fantastic!
I think this kind of feature is useful even if it can be circumvented, because deliberate circumvention would show a sign of bad intent and arguably be cause for account suspension or instance defederation.
It's similar to the situation with block evasion, which is often used to suspend or defederate as it shows bad intent by the evaders.
@FediTips Yes, social enforcement will likely play a role. We'll see if we can put something solid together!
Hey, thanks for pulling me into this discussion 🤠
I loved this FediTips article, and everything it advocates - especially issues of representation and culture here.
I have some opinions on reply controls and moderation, but I've been mostly a follower on the existing FEPs
I think @julian@community.nodebb.org is probably the leader on this topic.
If there's somewhere I can add, please let me know and I'm happy to help out.
@benpate If you don't particularly feel like getting deep into it, I can just ping you when the FEP is up in the public repository as a draft, if you want. There'll be the normal public feedback period after it's at a point where all the important parts are in place.
Right now I'm looking for close collaboration on architecture, impact analysis, maybe UI recommendations, and general writing. If that doesn't sound appealing then no worries.
@julian@activitypub.space if you want in on this let me know! 🙂
@julian Thank you for taking this up!
I don't really have any experience with writing technical proposals, and my understanding of ActivityPub is not super deep.
But you are right, this is something I would really love to see implemented by more fediverse platforms, especially Mastodon.
What would be the best way to help here?
@stefan The GTS docs already do a good job covering most implementation details. (Which is why I was hoping this could be done with a glorified copy&paste, oh well. 😅) But there are actually some loadbearing TBDs still in there, so there is architectural work to do, plus sections on consequences & limitations, UI recommendations and such.
As we speak it's a solo effort, so if we get a few people together, I guess we start a chat room and a shared live document. 🙂
@julian By the way, I'm guessing you've tried reaching out to the Mastodon team?
@stefan I actually haven't yet, lol. You're right though, if we're making this a little social club then might as well.
@andypiper, @renchap, @dave You've mentioned you're working on reply controls too (as more of a distant thing if I remember right), so of course if anyone on the team would like to be part of the FEP process, I'm happy to have you.
@julian This is on our roadmap, but we want to do it by considering the user experience first, and it's full of edge cases. Also one of the big (huge) question is: who can approve a reply? Right now with the GTS proposal it would be the post from `inReplyTo`. This makes sense on an AP/implementation level (and not too hard), but is not obvious if you consider the user experience.
Adding @Claire
@stefan @andypiper @dave
@julian So we need to consider if we want to switch to a "thread context”-based approval model, there the author of the root of the thread controls all the tree of replies. Which would be a big change for Mastodon (and similar implementations), but might be more aligned with what user want, and solve other issues as well (replies federation).
But that would be a *huge* undertaking, with lot of problems related to backward compatibility (for example)
@Claire @stefan @andypiper @dave
I really appreciate you thinking about this. The federation, the biggest advantage of the Fediverse, is also its biggest weakness when it comes to moderation. Regarding the thread-based model: I believe this is the method used by Fediverse applications outside of Mastodon. Mike MacGirvin has replicated much of what is used in the Hubzilla/streams project (including this thread-context-based model and nomadic identity) in ActivityPub in the Forte project. It might be helpful to take a look at this project.
@julian @Claire @stefan @andypiper @dave
@pepecyb
@jupiter_rowland
@zotheca Mike's approach is (I believe) documented at https://fediverse.codeberg.page/fep/fep/171b/ so we'd have to check whether to deeply study the implementation on top of that. I'm not in contact with Mike, but @julian@activitypub.space would be my go-to “context expert.”
Identity management considerations should (luckily) be orthogonal. 🙂
@renchap @Claire @stefan @andypiper @dave @pepecyb @jupiter_rowland
@julian@fietkau.social @zotheca @julian@activitypub.space @renchap @stefan @andypiper @dave @pepecyb @jupiter_rowland Mike's approach essentially has the author of the root post have the complete control over the entire conversation, which is not necessarily bad, but a huge departure from how Mastodon currently works, both in its UX and internals
going with GoToSocial's proposal seems much simpler and immediately useful, but i'm also not completely sure this is what people want, and it's unclear how to make the two cohabit or move from GoToSocial's approach to Forte's if we need to
@Claire Even in the context of the GTS schema, we're still wrestling with question marks. For example, @stefan's use case of locking replies on a busy post is not currently possible with it as written, without invalidating all existing replies (because automatically approved replies don't currently require individual approval). Gotta see what we can do!
@zotheca @julian@activitypub.space @renchap @andypiper @dave @pepecyb @jupiter_rowland
@julian@fietkau.social @Claire
Not sure if my question makes sense, but would it help separate disabling replies and more granular reply controls?
When we look at most requested features on Mastodon's GitHub, blocking replies is #1, Twitter-style reply controls are #10.
So it seems like being able to lock a post might be more helpful than being able to control who can reply.
@zotheca @julian@activitypub.space @andypiper @dave @pepecyb @jupiter_rowland
@stefan @Claire I don't think so, unfortunately. The difficulty comes with _changing_ who can reply to a post after it's already been published. The implementation difficulty between “no one can reply” and “followers can reply” is not all that big, the problem is being able to prove that my reply to you used to be legal before you edited the permissions on your post.
@zotheca @julian@activitypub.space @andypiper @dave @pepecyb @jupiter_rowland
@julian I think we're at the point where discussing this on a forum might be better, hate tagging so many people!
I guess I am starting to be a bit worried now. It does make sense that people are more interested in locking replies than being able to pick who will reply to a post.
The latter is basically a workaround for scenarios resolved by the former. You need to know which posts will attract harassment and plan ahead.
In my case, I posted a fairly timid pro-trans post once, and boy, you don't want to know the stuff I saw.
@stefan Yeah. If you don't mind tossing the existing replies, then it's not a problem. Or maybe we tell implementations to treat the replies collection on the post as authoritative and drop replies that aren't in there, I gotta think through what that might break.
For quote posts, Mastodon chose to do the mandatory individual verification, which caused much grumbling when it was incompatible with all other quote posting platforms. We can't afford to break reply interoperability like that. 🫤
I would think (and have argued) that the solution begins from treating the replies collection as canon. Anything not there is not an accepted reply. This makes the OP server and its real time reply policy (as well as the OP's later delete decisions) the primary source for discovering replies.
This reduces the distributed policy object to declaring what to expect as the default response from the OP server.
@julian @stefan
Another small but meaningful piece would be that replies to followers-only posts should be sent to the OP followers, and followers-only replies to a public post should be automatically rejected. Followers-only replies are a major harassment vector with basically no legitimate use cases.
@julian @stefan
@osma The first suggestion here requires a managed context. I'm in favor of it, but you've read the rest of the thread (I'm assuming). The FEP will leave the door open for it, but will not mandate it.
The second suggestion is an administrative decision that I see as orthogonal to reply controls. If server admins want to blanket disallow replies with reduced visibility, they can do that today, no user-facing interaction controls needed. Could be a good change.
Both reply controls and disallowing followers only replies require that replies are posted to OP server, added to replies collection if policy allows, AND other servers defer to OP server's replies collection for what are valid replies. The last point is not what Mastodon does today, and that breaks everything else.
@julian @stefan
@osma My suggestion was that servers could disallow followers-only replies without looking at reply collections at all. But it could also happen as a side effect of honoring them, yeah, assuming the poster's server blocks them. Interaction controls as per the GTS schema can filter automatically by author and follow relationship, but not (yet) by reply visibility.
@osma Servers rejecting different sets of replies is already the status quo due to defederation. I doubt filtering reduced-visibility replies unilaterally would change that situation much, especially so for explicitly abusive followers-only replies. Those are already intended to be seen only by the OP and the abuser's buddies, who will probably never honor interaction policies or reply collections anyway. Can't stop people from talking about you on their own website.
- Moderation being reactive rather than proactive
Mastodon moderation currently relies on reports of bad behaviour: something bad happens, someone reports it to moderators.
If there was a system to automatically alert moderators to certain keywords, they could respond much more quickly to hate posts (and spam and many other problems too).
The mods would still be human, they would just be alerted more quickly.
Github users can vote for this at https://github.com/mastodon/mastodon/issues/21306
🧵 Thread - Part 4 of 7
@FediTips That's an interesting idea, but it must be very cleverly made, because there are many ways to circumvent any pattern filter.
There are always ways to circumvent, but someone doing that shows bad intent and makes it easier to just ban them.
This happens currently with block evasion, people get suspended purely for the act of block evasion because it shows bad intent.
So, even imperfect systems are very useful 🙂
@FediTips I agree with that. They still have to be extra careful which is more than enough.
- Allowlists vs blocklists
By default a server federates with all other servers, unless a server is on their defederation blocklist. (Masto admins can find out more at https://fedi.tips/how-to-defederate-fediblock-a-server-on-mastodon ).
This is ok if you want to communicate with as many people as possible, but can cause problems if you're targeted by hate.
Admins who need to prioritise safety over connectivity may want to consider allowlists instead of blocklists. More info at https://fedi.tips/creating-an-isolated-server
🧵 Thread - Part 5 of 7
- Cultural problems
The culture of a platform is so all-encompassing that it can feel like there's nothing that can be done to change it.
Perhaps there is at least one thing you can do to help though: Listen to a member of a vulnerable group if they find this place unfriendly. Bite your tongue if you feel like trying to convince them otherwise.
Listening should make problems clearer and change easier. (This is also a strong reason for diversity in software development)
🧵 Thread - Part 6 of 7
p.s. Admins should try activating Secure Mode
Secure Mode (aka Authorized Fetch) is a setting on Mastodon that admins can activate which makes blocks MUCH more effective.
It's off by default due to historical technical issues, but it works really well nowadays. I'd highly recommend admins at least try it, more info at https://fedi.tips/authorized-fetch
(It had a reputation for affecting compatibility and resources, but at least on my server it has run totally fine for years.)
🧵 Thread - Part 7 of 7
