"...
How a healthy federated network can look like
To me, this leaves a final idea of how federated systems should be designed. The key points:
Monopolies must be under control. Large instances have a great power and responsibility. If a large provider decides to cut the connection, it will be the smaller party to be blamed. This has been the case with E-Mail, where all small providers need to comply with the rules of Google, Microsoft etc. Users expect third-parties to successfully deliver the messages into their inbox and do not question if their provider plays a fair role in the game. We believe that community-managed structures like Codeberg also play an important role. The decision is in the hand of the public and does not depend on the arbitrary decisions of a company or small admin team.
Moderation must federate well. Instead of relying on only two sides of the connection to process reports, it might be beneficial if abuse reports are also shared to other instances. An instance could automatically hide posts if they have been blocked by numerous remote servers. This prevents malicious instances from generating duplicate work on all receiving servers.
Responsible maintenance. It is good to allow anyone to selfhost software. However, putting up something on the Internet comes with some responsibilities. Unmaintained systems can cause harm, unpatched software or insecure configurations can be the entrypoint for spam or can be combined to botnets with huge impact. Please consider twice before offering a service with open registrations. If you want, we recommend forming a group of like-minded admins and taking care together. This is more efficient – and more fun!
Build a network of trust. I believe that downloading blocklists from third-parties is not the ultimate answer, but knowledge sharing is. You almost always have some remote instances which you trust. I imagine Codeberg trusting instances maintained by team members, Forgejo developers and other like-minded communities (e.g. disroot). And we trust their trusted instances, too. This repeats until a certain configurable threshold. Everyone else needs to be approved by moderators first, before the spam can reach our users. This keeps a balance between protection and manual effort.
What we can learn from the Fediverse spam for Codeberg
https://blog.codeberg.org/what-we-can-learn-from-the-fediverse-spam-for-codeberg.html
