In the interests of starting a more productive dialogue than yesterday's main character was interested in, let's make a #brainstorm thread about design changes to ActivityPub and/or client UI that could actually help address drive-by (often racist) harassment on the fediverse.

Feel free to discuss pros/cons but don't feel an idea needs to be perfect to suggest it. Also since this is a brainstorm don't worry about complexity/implementation cost. If you have a great-but-hard-to-implement idea someone else may think of a way to simplify it.

Note that the underlying problem *is* a social one, do there won't be a technological fix! But tech changes can make social remedies easier/harder.

I've got some to start:

1. Have a "protected mode" that users can voluntarily turn on. Some servers might turn it on by default. In protected mode, users whose accounts are less than D days old and/or who have fewer than F followers can't reply to or DM you. F and D could have different values for same-sever vs. different-server accounts, and could be customized by each user. Obviously a dedicated harasser can get around this, but it ups the activation energy for block evasion and pile-ons a bit. Would be interesting to review moderation records to estimate how helpful this might or might not be. Could also have a setting to require "follows-from-my-server" although that might be too limiting on private servers. Restriction would be turned off for people you mention within that thread and could be set to unlimit anyone you've ever mentioned. Would this lock new users out of engagement entirely? If everyone had it on via a default, you'd have you post your own stuff until someone followed you (assuming F=1). One could add "R non-moderated replies" and/or "F favorites" options to soften things; those experiencing more harassment could set higher limits. When muting/blocking/reporting someone who replied to your post, protected mode could be suggested with settings that would have filtered the post you're reporting.

2. Enable some form of public moderation info to be displayed when both moderator and local server opt-in. Obviously each server would be able to ignore federated public tags. I'm imagining "banned from X server for R reason (optional link to evidence)" appearing on someone's profile & an icon on their PFP in each post viewed by someone on server Y *if* the mods of server X decide it's appropriate *and* server Y opts in to displaying such tags from server X specifically. Alliances of servers with similar moderation preferences could then have moderation action on one server result in clear warning propagation to others without the other mods needing to decide whether to also take action immediately. In some cases different moderation preferences would mean you wouldn't take action yourself but would keep the notice up for your users to consider. Obviously the "Scarlet Letter" vibe ain't great, but in some cases it's deserved, and when there's disagreement between servers about that, mods on server Y could either disable a specific tag or disable federation of mod tags from that server in general. Even better shared moderation tools are of course possible.

3. Different people/groups have different norms around boosting. Currently we only have a locked/public binary. Without any big protocol changes, adding a "prefers boosts/doesn't" setting which would warn in the UI before a viewer chooses to boost if the preference is "doesn't" could help. This could be set per-post, but could also have defaults and could have different values for same-server or not, or for particular servers. For example, I could say "default to prefer boosts from users on my server but not from users on other servers" or "default to prefer boosting on all servers except mastodon.social." Last option might be harder to implement I guess.

#ActivityPub #Meta #Harassment

Follow-up: a version of #1 for visibly-to-a-user already exists in at least one client:

https://pachli.app/pachli/2025/02/28/2.10.0-release.html#anti-harassment-controls-for-conversations-private-mentions

Having it happen at the server level where the post gets dropped would be better.

Thanks @smallcircles for the pointer to the fediverse ideas repository:

https://codeberg.org/fediverse/fediverse-ideas/issues

Pachli 2.10.0 released

Pachli 2.10.0 is now available. This release adds anti-harassment controls for Conversations (Private Mentions), improves the UI when replying, updates the Atkinson Hyperlegible font, and more.

Pachli

@tiotasram interesting ideation topic.

Not sure if I have time to respond today, but just wanted to note that this aligns with the general interest and focus of Social experience design (SX) at https://coding.social which I elaborate on as a hobby, and perhaps one day my job.

The disadvantage of microblogging is how ephemeral it is, but the advantage is reach. Should you be interested you are welcome to share results on the social coding forum, which serves as a note-taking tool: https://discuss.coding.social

Also there's the fediverse-ideas repository on codeberg at: https://codeberg.org/fediverse/fediverse-ideas/issues

#SX #SocialCoding #SocialWeb #ActivityPub

Joyful creation for the Social web

We reimagine the social web and cocreate a peopleverse.

Social coding commons

@tiotasram Great thoughts! Your first thought made me wonder about bot farms: an opponent wishing to defame a person could overcome all of the defenses you suggest simply by hiring the services of a bot farm.

Unfortunately I see to defense against that.

@aeveltstra

Bot farms would become known pretty quickly and could be blocked in a shared blocklist, no?

@tiotasram

@alessandro @aeveltstra yeah that's a hard problem to solve especially if they do something like use LLMs to break CAPTCHA and sign up for mastodon.social or some other instance with open sign-ups automatically. But presumably very few of the racist harassers on here are that dedicated. It's definitely not an outright solution to the problem but it might be able to help a bit?

@alessandro @aeveltstra there is interesting research on this (it's called a Sybil attack in general), but it's a very hard problem.

Might be interesting to be able to define interaction rules based on open-signup vs closed-signup servers and have each server publish which category they're in.

I do think "the perfect is the enemy of the good" here as well. If something like this could make even a few percent dent in racist harassment it might be worth it?

@tiotasram @alessandro @aeveltstra

Another and easier harrassment vector is public (or follower-only) data extraction from the fediverse to learn PII about fedizens and spread their opinionated quotes as red meat in extremist (usually right-wing) circles. Let the festering anger in these crowds do the work, and fedizens getting harrassed in all the channels they are known to communicate in.

@smallcircles @alessandro @aeveltstra

This is a much harder harassment vector to defend against but might be less common than the direct racist replies? You really do need something like locked mode (or better) to defend against this type of stuff, which then comes with the tradeoff that your social circle is shrunk considerably... Most people don't want to be forced into locked mode all the time, I suspect.

@tiotasram @alessandro @aeveltstra

Yes, good protection would ideally be part of a social network that has more fundamental changes in its core mechanics to be able to support that, and not go from the basis of fediverse-we-have - following well-known (traditional) and microblogging-heavy social media models - and try to add safeguards and (top-down) governance after the fact.

@tiotasram @alessandro @aeveltstra

What is ironic is that we model online social networks in all kinds of ways, except after our own offline social networks. 😅

SX introduces Personal social networking where more attention to that is given..

https://coding.social/blog/reimagine-social/#personal-social-networking

How We Reimagine the Social Web

We find novel ways to collaborate and create value together.

Social coding commons

@tiotasram @alessandro @aeveltstra

If you want to ponder how to #ReimagineSocial then my blog post on #SX and #SocialCoding may be intriguing. It contains a brainstorm section and encouragement to chime in on that too..

https://social.coop/@smallcircles/116379158584600016

@tiotasram Quarantine periods for new accounts, especially on open registration servers. The details could be configurable, but basically, new accounts would be unfederated for their first month. They could follow any accounts already known to their host server, but could only boost, fav and reply to posts from accounts on the server they're on. Admins could waive the quarantine on an account-by-account basis.

Three benefits:
1. It raises the investment level for creating troll accounts, which serves as a deterence.
2. It allows mods to observe new account behavior before unleashing them on other servers, which helps contain reputational blowback.
3. It narrows new arrivals' focus early on so that they're encouraged to familiarize themselves with the local community first.

@tiotasram

There are better descriptions for this harassment vector and maybe there are some good ideas for how to improve.

Basically a harassing reply in a thread where scope is set to followers only (and by default the original poster). Abuse the original poster sees but most others in the thread don’t.

https://ruby.social/@stepheneb/116358526764550008

Stephen Bannasch (316 ppm) (@[email protected])

@[email protected] There have been some serious architectural issues that enable harassment which also hides the harassment from others. The details are important but I can only give a flavor (will look for a post that explains it well). Goes something like this: User0 (person about to be harassed) posts. User1 posts racist reply and sets visibility to “followers only”. That actually means followers only plus User0. 1/n @[email protected] @[email protected]

Ruby.social

@stepheneb yes, ideally tech could make it easier for users and/or moderators to prevent the reply in the first place (my proposal #1). Making it visible-to-all makes the problem somewhat less pernicious since at least the targets (hopefully) would get less gaslighting from strangers about the level of racism, but they've still been harassed.

One could imagine giving moderators the ability to break followers-only visibility (feels weird and abusable) or at least after cleaning it up have the option to leave a note that shows to a viewers of the original post "X replies to this were banned for Y reason". That has the advantage of boosting visibility of harassment without propagating the racist messages themselves.

My thinking was that if the drive-by reply is in part to provoke a pile-on, even when protected mode doesn't block that reply, it might block some fraction of only-following racist hangers-on from jumping in. It could also be useful against simpler forms of block evasion.

@tiotasram are you coming to @fediforum ? This would be a great follow on from one of the discussions at the last FediForum about racism on the Fediverse.

@alexisbushnell @fediforum no (don't have conference bandwidth even for coferences in my own field right now) but anyone is welcome to steal these ideas and bring them up.

If anyone knows of an open database of moderation actions (or a server whose mods might be willing to share such) I might be able to scrounge the time to do some analysis though? I haven't dipped any toes into fediverse development just yet myself sadly.

@tiotasram @fediforum I get that. Thanks, I'll bookmark your post and try to remember to bring it up at FediForum in case someone with more techy know how than I can run something around it.

@tiotasram here's some thoughts from a couple of years ago. https://privacy.thenexus.today/steps-towards-a-safer-fediverse/

FIRES is a mechanism that could be useful for your point #2. https://fires.fedimod.org/

Steps towards a safer fediverse

Part 5 of "Golden opportunities for the fediverse -- and whatever comes next."

The Nexus Of Privacy

@jdp23 not having good knowledge of the spec, I wonder how hard it would be to create an opt-in mechanism for people to post as a "moderated thread" such that the OP could remove replies from their own thread directly (but only for this special type of thread, and the reply posts would still exist, they just wouldn't be displayed as part of the thread by default).

People could always quote or link to interact externally without permission (usual instance moderation would be the resort to abuse of that) but it would give people who want it more immediate control to respond to harassment/trolling without having to wait for a mod team response. Those who think this gives too much power to OP could simply not engage with such threads or with people they feel are abusing them.

The ability to remove replies from threads is certainly something that's been requested. It's challenging because Mastodon doesn't really have a concept of "thread" (as opposed to Lemmy, Piefed, NodeBB, and other "threadiverse" apps). In fact today there isn't even the ability to remove a reply to a post, let alone something several posts down in a thread.

(In principle the same kind of mechanism that's used to revoke authorization for a quote post could be used for removing replies to posts. But, there's a challenge that replies on Mastodon today are implemented without checking for any authorization (so there isn't anything to revoke). Mastodon is planning on implementing interaction controls on posts in general (not sure of the time frame), and last I heard they were planning on reusing the same mechanism they use for quote posts ... if so, then it seems to me like the ability to remove replies to posts will be there in general. But that by itself doesn't help address the thread aspects you're talking about.)

@tiotasram

@jdp23 I guess if you wanted to do it right now you'd have to provide metadata about user moderation decisions attached to these OP and let clients try to respect it as they assemble threads. Then it would only work for clients that implemented the feature, which defeats most of the point.
@tiotasram yeah making any changes like this in a federated system is really tricky -- you have to take other platforms as well as clients into account.

@tiotasram

If I might offer something from the user perspective, and specifically for new users...

Anything that might be added in terms of controls or moderation features - especially when they occur 'up front' and before any communications take place might want to keep onboarding considerations in mind.

If it will be a user toggle feature, perhaps default it to opt-in, not opt-out _during_ signups. Alert users, and get their choices at setup time. Ensure it/they are known beforehand.