Back

@ajsadauskas
The lack of safety tools here grates. Notably not being able to limit:

1. who can reply to your posts whilst keeping them visible

2. Who can tag you whilst being visible

Key ways to attract and _vet_ potential members of a community.

Without this, someone gets tagged by bad actors, suffers a pile on and it's _entirely invisible_ to everyone else who might pitch in to help which _isolates_ the person attacked.

Basic stuff.
@mekkaokereke @timnitGebru @KimCrayton1 @samuteki

@Homebrewandhacking @ajsadauskas due to the nature of the fediverse, these are hard to tackle issues.

you could have post with a certificate attached and when people want to reply, they ask your instance to authorize their reply. Compatible client would check reply authorisation against the certificate and hide unauthorized replies.
One possible solution.

For tagging, maybe throw-away account, hiding your identity unless the people looking follow you. It's doable.

@gkrnours

I'm not a tech person so I don't grasp the implications of what you're saying.

That first one sounds like discussions about "authorised fetch" which is controversial because it increases running costs.

I don't think you've grasped what I'm saying with your second point: a marginalised user needs to be visible to build community. Throw aways aren't going to do that.

These problems are hard, or they'd have been solved already?

@ajsadauskas

@Homebrewandhacking @ajsadauskas the big issue is, because each instance do it's own thing, you can control only what you send.

The first would add a single operation per reply, which yes would add to the cost a bit I think. But this requires buy in.

the mob tagging problem is hard. The idea for the throw-away was to have a target for the abuse. A long term one could be called a stage persona. But that wouldn't help much as the hate would still be here :(

These are issues that need fix.

@gkrnours @Homebrewandhacking As a starting point, the shared auto-updating blocklists @mekkaokereke describes here could be a good place to start:

"You should be able to go to your Mastodon config, and subscribe to a series of auto-updating blocklists from sources that you trust. These should be combined with your own blocklist."

https://hachyderm.io/@mekkaokereke/112860109548583248

There's a number of ways that idea could potentially taken further.

For example, which blocklists a given instance subscribes to could be listed in Fediverse directories, and on the front page or sign-up page of each instance.

Or the list of instances that subscribe to a particular blocklist could be treated as a white list for instances that serve a particular community.

So an instance that predominantly serves Black users could only federate with other instances that have implemented a blocklist that bans anti-Black trolls.

Or an instance that predominantly serves trans users could only federate with other instances that have implemented a blocklist that bans anti-trans trolls.

@ajsadauskas

Yes, there is at least one project underway to implement a "whitelist" of servers. It attracted considerable controversy, although how warranted that was I couldn't tell you.

@gkrnours @mekkaokereke

@gkrnours @Homebrewandhacking @mekkaokereke That's why I suggested that they could whitelist instances that apply a particular blocklist.

So say there's a group of instances that only federate with instances that apply a given blocklist.

Say you also have a small 12-user instance. Or even a single-user instance.

As long as that small instance applies said blocklist, the instances in that group will federate with it.

If it doesn't, then they won't.

@ajsadauskas @gkrnours

I do not believe "seperate but equal" to be a good solution. One where Black people get a second class Fediverse does not seem attractive to me and I am not Black.

@mekkaokereke