So, what would “Better Safety Tooling” on the Fediverse look like?
And, what would meaningfully help the Fediverse to serve more people?
—
Tagging @laurenshof because you had some interesting insights I’d LOVE for you to expand on :)
45
Replies
·
0
Boosts
everyone seems to understand websites (public attention), group apps (private communities) and email (potentially so bothersome that users need moderation help at the server level). we've managed letting people post whatever they want forever and ignoring it. we created spaces for only certain interested people. we address spam.
we're going to struggle as long as we're not clear on our goals. I don't think it's a tool or org problem. we mostly don't want the same thing.
To use a physical metaphor, we've built technologies that allow anyone in the world to walk into our house and sit at our kitchen table.
Blocklists ban the people completely AFTER they've behaved badly. Shared blocklists let us tell neighbors not to let them in.
In real, human communities, relationships are more complex than binary accept/deny lists. We rely on reputation, relationships, and word-of-mouth referrals.
Perhaps we could model those aspects here, too.
@benpate @wjmaggos @laurenshof yeah, that's the ROSCA model & we need a digital equivalent. Essentially, it's networks of trust. We attest for each other, & introduce new members into the network. However, there's a lot of research into how large networks can get before they break down. My suggestion is that instances should deliberately limit their membership to reduce that cognitive load. An instance attests for its members. Instances attest for each other.
@wjmaggos @benpate @laurenshof
Yes! Better support for different modes of communication. Offline we rarely stand on a soapbox on a market square shouting at a crowd, and as we are weaving in and out of different social contexts we switch between communication modes. The backbone of the fediverse is a distributed microblog, with very particular social dynamics. Our posts are public, advertised, reach unknown strangers, people chime in on context collapse. Soapbox comms lead to unhealthy influencer culture, in-groups, purity spiral anti-patterns.
There's both a safety and inclusion aspect. Block and mute are harsh, cruel tools for ostracisation and shadowbanning, should be reserved for bad actors only. Yet its used for curation and timeline filtering. Their use is understandable, there's nothing else, but there's an extreme human laziness if people who know each other for years just slam the block button. How about the decency to bring up a grievance. It makes fedi shallow, parasocial.
1. Shared blocklists, at the user and server level, configured by default in Fediverse server software
2. Content filter API servers, like Akismet
3. Fix followers-only on Mastodon
4. Private groups
5. E2EE messaging
6. CC licenses for content
We need to make public participation more explicit, and make it easier to participate privately.
@evan Blocklists have a flaw, and need to improve at all costs.
@benpate @evan @laurenshof If I understand correctly what you mean by "trust relationships", this relates strongly to something I blogged about lately:
All popular platforms I know of in the fediverse offer connection-roles in more or less the same way as X and Instagram do. The role-system adopted by LinkedIn and Facebook offers higher trust relations on top of the simple "follow" model: "connections" and "friends", respectively. (I describe this in detail in the post I link below) I believe this is an important distinction, which may be the reason why Instagram and X are arguably more toxic than Facebook and LinkedIn.
https://blog.gillesdutilh.com/2026/06/mutuals-are-not-friends-2/
@benpate @evan @laurenshof If I understand correctly what you mean by "trust relationships", this relates strongly to something I blogged about lately:
All popular platforms I know of in the fediverse offer connection-roles in more or less the same way as X and Instagram do. The role-system adopted by LinkedIn and Facebook offers higher trust relations on top of the simple "follow" model: "connections" and "friends", respectively. (I describe this in detail in the post I link below) I believe this is an important distinction, which may be the reason why Instagram and X are arguably more toxic than Facebook and LinkedIn.
https://blog.gillesdutilh.com/2026/06/mutuals-are-not-friends-2/
I've found @DePemig 's work very helpful for me in thinking about social trust.
"Mutuals are not friends" is a key insight that a "Follow" is a helpful signal, but not as strong as we often make it out to be.
This is why I'm hopeful we can make progress on "Endorse". It *is* a bit more fiddly, another command for users to understand so I do worry about making things more complex. But it is a significantly stronger signal, an explicit trust signal (vs interest signal that Follow indicates)
@benpate @evan @laurenshof
@benpate @laurenshof I'd also say: more implementations of 'indexable' and 'discoverable'.
I love this. Yes.
And, a generalized solution, if that’s even possible.
For consent on Bandwagon, I had to roll my own. When you publish an album, the last step is to check on/off any partners who are allowed to rebroadcast your stuff.
There’s a “select all” to be included when new partners are added. This is super important, because new things come along (like Bridgy.fed) that don’t match our pre-existing models.
It sucks to keep adding more Boolean flags to the model.
@benpate i think "better safety tooling" is a bit of a red herring, because the real problem is in figuring out who has the authority to set boundaries.
assume the current fediverse/mastodonishverse/whatever to be a "bounded space". exact boundaries and technical details dont matter yet. it is a shared "space", that has some boundaries and values that people want enforced within those boundaries.
(examples can be "no cloudflare" or "relays should be optin", or whatever)
/1
so now you want to improve this "bounded space" with some rule/tool/thing, that makes the space "safer" (for any definition of safer)
the core problem is that the functionality of this Thing are contested by its nature, but that there is no source of authority who can make the decision for the entire space (decentralisation yadiyada)
so any rule/tool/thing that matters cannot get community buy-in because it is contested and nobody can dissolve the contestation
/2
@laurenshof I love this line of thought. Thank you!
So far, I've naively assumed two boundaries: server (chosen by admins/mods) and user (my own personal blocklists)
But that doesn't really follow the way our natural communities cross-cut the Fediverse, does it?
@benpate @laurenshof what if we evolved our thinking beyond blocklists? Like we've tried that for nearly a decade, with import/export since early 2023, can we honestly say they are building healthier better communities?
They're a very coarse moderation feature, but maybe consent based federation would be better? Or granular policies?
@benpate yeah, my most radical opinion is that i dont think servers actually exist, in the sense that they dont actually meaningfully play a part in either how we understand the socially constructed object 'fediverse', nor in how this "fediverse" again shapes our social understanding (via the posts entering our feeds through which we create our social perception of the fediverse)
@benpate calling cloudflare fascist is very easy. figuring out a rule/thing/object that causes 'no cloudflare' in this bounded space is hard, and implementing that rule/thing/object is literally impossible
thats why were stuck in this endless cycle of discourse and yelling, because there is no structural way to break out of it
Cc: @oli I suspect you have thoughts on this. I hope you don't mind me tagging you in.
Thanks! And yes. FIRES looks like a fantastic part of the solution :)
@benpate @trashpanda @laurenshof To be clear, I just use FIRES and implement the FIRES protocol, (via Pelago) but the author of FIRES is @thisismissem
All respect and credit for the development of the protocol itself goes to her. I'm pretty sure I've nailed it as far as emulating the reference server and mirroring the data structure and outputs, but we'll see how close I come to passing FIRES conformance tests once those come along.
To your larger point, I have other ideas about "networks" as I loosely refer to them, but the elevator pitch is that you either have the 'default network' which is "this", what we have right now, everything is opt-out and from that we have the 'Mastodon covenant' network and the 'alt-fedi' network and the 'crypto-enthusiast network' and the 'I don't want to be moderated at all liberatarian network', etc, all smashing into each other.
Hence why I keep pushing island networks. It's opt-in networking, it's entirely consensual, it's unique to the fediverse, and it's something only we can do, and it scales horizontally rather than vertically.
But it's a separate, structured, safer subset of the fediverse, with a clear list of rules on the door. So no one has to wonder what this network says the network is for, what is allowed, what is not allowed, for all instances and individuals within the network.
@oli@olEmeliasocial @trashpanda @laurenshof @thisismissem
1. Yes. Emelia is a rock star.
2. I'm excited to implement FIRES. Do you have any guidance for a noob?
3. I like the "island/archipelago" in principle, but still hope some services may cross-cut the opt-in-ness of this design. For instance, I like music, tech, pirates, and snowboarding. I'd hate for the long-running snowboarders vs. pirates feud to make me choose between those two archipelagos.
