A thousand instances each guarding their own place, with no shared obligation or collaboration, with no place to maintain the commons that is the network itself
20d 5h ago by piefed.social/u/rimu in fediverse@piefed.social from connectedplaces.online
This week, the Catholic Church wrote one of the better diagnoses of why decentralised social networks keep struggling.
...the collaboration between instances on things like moderation is virtually nonexistent. There is no form of federated diplomacy, or even a mental framework on how servers should interact, besides defederation when you get too annoyed with another server....
... [On the other hand, with BlueSky there is the opposite failure mode:] solidarity without subsidiarity is the benevolent provider of infrastructure: one big network that takes care of everyone and quietly removes their agency."
I suppose the author assumes that instances are only federating with another to achieve their shared interest of providing content to their users and that they will defederate when the burden of moderation becomes too great for that amount of content, but if that were true then instances would be federating with a whitelists of instances, rather than blocking only selected ones. Clearly most admins want their instance to federate with all and many others, yet the author asserts there would be no solidarity based on the fact that admins and mods only moderate their own users and spaces. The author also asserts there would be no concept of diplomacy, but when the admins 'get too annoyed with another server' they surely would know how to reach out to another or how to discuss things in public, like we've seen atleast on the threadiverse many times, rather than jumping to the defed button‽
What are the modes of solidarity that could be introduced in the fediverse?
Shared blocklists is one. There might also be a hint of it in the starter packs that Mastodon is now implementing.
In the threadiverse, there's an element of it in how communities are hosted all over the network. If Mastodon introduces groups that could have a similar effect.
Any other ideas?
I would envision something like "receipts" for federation and blocking.
From my understanding, activity stream objects (ie posts, comments) are cryptographically signed by their emitting instance. This means ban-worthy comments and defederation-prompting behaviour can be exhibited and "proven", in a sense, not to have been falsified. In turn we could cultivate an expectation that blocklists provide receipts. Currently, many that I see are just a list instance domains or usernames, without no concrete examples of what they did to merit their bans. This has led to a certain amount of concern-trolling imo, and I've seen accusations and counter-accusations of racism and queer phobia between fedi instances and their admins that should (again, imo) be capable of finding common ground yet no one ever shows the offending material or behavior, they just describe it as warranting the blocklist.
The instance my mastodon account is based on, for example, defeds with fosstodon, and I can't help but feel that a certain number of people I see on that instance would migrate elsewhere if they were aware of the current state of things, yet I myself can only parrot the vague accusations of bigotry given by my instance's admins - all to easy for them to not "see the problem" in their day-to-day if they're instance's admins are remotely competent. I'm reminded of an article that came out like a week or two after charlie kirk's death reflecting on how the author's neighbor was blissfully unaware of all the awful things that man had said and done, and viewed him as a "family man", because of how their social media experience had curated that exposure of him for her.
Rumours and hearsay are not a good foundation for exclusion, and if there's no transparency in delegation of exclusion, then we won't make meaningful differences compared to centralized, authoritarian, private social networks.
Well, the Pope in his encyclical is talking about the Catholic concept of Solidarity which has to do with the common experience of humanity and having works be for the benefit of all of humanity. It's a much more broad and ecclesiastical than the strict definitional term.
Solidarity in this sense applied to the Fediverse would be more about how the fediverse connects people towards a common goal of communicstion. Bluesky doesn't have solidarity as implied because it's centralization isn't solidarity. When it became popular, Twitter, in transmitting and aggregating short bits of data across the internet, did: the technology was agnostic to the content. That's where there's "solidarity" in Bluesky: as the idea and concept of Twitter now exists beyond both BS, X, TS, and so on.
Shared block lists and such though is just building another Catalogue of Abominations.
The Mastodon Covenant is an interesting case. This sets out the minimum standards that instances must meet to be included in joinmastodon.org. I don't know the process by which it came to be, maybe it was just an edict handed down or maybe there was some community input... The point is it's an example of something that governs how we are together. Instances can opt in to it, they gain certain benefits and we all gain increased confidence in the fediverse.
Anyway, some process and place where covenants / treaties / accords can be hashed out and instances can indicate that they've signed on to them.
There could be standards developed for
- the setting up of hotlines to be used during emergencies
- minimum moderation standards
- agreed upon break-points where defederation is expected and acceptable
- recognition of important dates and festivals
- anti-brigading agreements
- abuse / spam / csam reporting process/venue
- privacy expectations
- technical things like inbox flooding limits, media attachment sizes, security disclosure norms
and so on
Shared moderation, but ultimately being able to define communities as full fediverse thing, like the evolution of lemmy's or piefed's communities: make their management entirely possible through ActivityPub
What sort of community management is not possible with the current activityPub architecture?
The architecture can do everything; what's missing is the actual implementations working with it