It is depressing if someone experiences hate on here, especially if it puts them off using this place.
-
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
@FediTips I would also very much like the ability to (a) share my blocklists via API, and (b) automatically or semi-automatically implement blocks from trusted instances. (Each instance could be automatic or manual-verification, but there'd be a notification for admins either way.)
Whenever I propose this, someone always says it would lead to problems -- but I have yet to see a good argument for how.
-
@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?
-
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 problemsLet's look closer...
🧵 Thread - Part 1 of 7
@FediTips Friendica, and I think Hubzilla also, have followers only functionality already. So it's definitely possible to do in other ActivityPub projects.
Projects focused on maximizing "growth" hate follower only functionality though. (Which I've never understood because the biggest social network on the planet, dwarfing others combined, has followers only as a core feature)
-
@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?
@julian Also, I presume you know about https://socialhub.activitypub.rocks/t/fep-5624-per-object-reply-control-policies/2723?
-
@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 Also, I presume you know about https://socialhub.activitypub.rocks/t/fep-5624-per-object-reply-control-policies/2723?
@stefan Yes, I believe the heritage goes from FEP-5624 to GTS to FEP-044f. I'm hoping to FEP-ify the GTS schema in a way that harmonizes with 044f. I'll cautiously say that 5624 is encompassed or obsoleted by what GTS covers.
-
@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?
-
@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. -
@FediTips I would also very much like the ability to (a) share my blocklists via API, and (b) automatically or semi-automatically implement blocks from trusted instances. (Each instance could be automatic or manual-verification, but there'd be a notification for admins either way.)
Whenever I propose this, someone always says it would lead to problems -- but I have yet to see a good argument for how.
@woozle The problem with automated blocklist propagation is that you're now delegating fediblock-level moderation authority to every person that can add an instance to the list.
If the only instances added are objectively nasty ones, no problem. The problem comes from the mushy edge-cases and interpersonal catfights: Someone who gets into a fight with a small-time server operator that has the authority to add to a well-used list could find their entire instance blackballed by a rather significant chunk of fedi, from one lone person's actions and no review by any of the other instances that are enforcing the list.
That's not to say that lists are inherently a bad thing, just that automated lists are blindly trusting other people to not over-block. A much less prone to abuse/fuckups solution would likely be a moderation queue: mods of a 'unionized' instance get a report in the queue whenever another instance in the union adds a fediblock. Local mods can then review it before enacting it themselves.
-
@woozle The problem with automated blocklist propagation is that you're now delegating fediblock-level moderation authority to every person that can add an instance to the list.
If the only instances added are objectively nasty ones, no problem. The problem comes from the mushy edge-cases and interpersonal catfights: Someone who gets into a fight with a small-time server operator that has the authority to add to a well-used list could find their entire instance blackballed by a rather significant chunk of fedi, from one lone person's actions and no review by any of the other instances that are enforcing the list.
That's not to say that lists are inherently a bad thing, just that automated lists are blindly trusting other people to not over-block. A much less prone to abuse/fuckups solution would likely be a moderation queue: mods of a 'unionized' instance get a report in the queue whenever another instance in the union adds a fediblock. Local mods can then review it before enacting it themselves.
@woozle The other problem requiring some by-design moderator intervention prevents is "oops, someone fucked up and accidentally fediblocked all of dot-social" so the mistake doesn't propagate to every 'unionized' server before anyone can stop it.
Humans generally make lots of small-scale fuckups. Automation that isn't very carefully thought out can very quickly turn those into very large fuckups, as Cloudflare and AWS have learned the hard way many times over.
-
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.
-
@julian By the way, I'm guessing you've tried reaching out to the Mastodon team?
How do you actually propose a feature?
I think it would be nice to add a weight to the timeline so that user accounts show up at the top. Most accounts I follow don't post as often as the hastags I follow so they tend to get lost in the soup.
I think of it similar to telling your file explorer to list the folders first kind of thing.
-
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!
-
@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!
Let me lurk, just to see where this is heading? It's one area where I want to do a much better job in my own software. I just know that others have SO MUCH more experience here than I do, and this is a topic where I need to listen before I speak
-
Let me lurk, just to see where this is heading? It's one area where I want to do a much better job in my own software. I just know that others have SO MUCH more experience here than I do, and this is a topic where I need to listen before I speak
@benpate Fine by me!
Only there isn't a place to lurk yet because the possibility of including others in the writing process occurred to me just a few hours ago. Still gotta decide where we hunker down after I know if it's just going to be me, you, and @stefan, or if there are going to be more people wanting to help out.I think I want some sort of chat room for this, and a live document. Maybe CryptPad can render Markdown?
-
- 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 #GoToSocial already has this.
-
- 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.
-
@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 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 -
@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 @daveI 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
