Rabble on Nostr: This isn’t for nostr folks, but I wanted to cross post / share it here because I ...

This isn’t for nostr folks, but I wanted to cross post / share it here because I think people might find it interesting.

This is a proposal for the future of Bluesky and the at_protocol that would accommodate both the desires of the community of early adopters and also the vision of an open social media protocol.

**Building a Community**

Bluesky has successfully built a thriving community on its initial test server. With its own norms, culture, and even inside jokes like the sexy alf, it's more than just a test server. It's become a significant entity in its own right, with a community of 600,000 users.

**Facing Conflict**

However, it's not all been sunshine and rainbows. The server has become a site of considerable conflict. There's a fundamental gap between those who advocate for an open, decentralized protocol and others who desire a more actively managed social space. The vision that drives the project and the evolving values of its growing community have created tensions within the Bluesky team.

**Addressing the Challenge**

Both a federated social media protocol and a commitment to actively policing against bigotry have merit. But these two goals aren't entirely compatible. So, what if they didn't have to be? What if the current Bluesky server continued as a standalone entity, running updated Bluesky software, while the company simultaneously launched the atproto network using the same software?

**Accommodating Users**

Current users could choose to stay on the existing server or utilize key migration technology to move their accounts to another server that's part of the open network. They could maintain the same identity on both platforms. This approach would allow users to choose their preferred experience.

**Managing Speech**

In a fully open, decentralized social media protocol, managing speech in the way that many early Bluesky adopters envision may not be feasible. You can block and mute objectionable users and content, but you can't prevent them from using the protocol altogether. This highlights the inherent tension between the preferences of early Bluesky adopters and the open-source, open-protocol nature of what the company is building.

**Examples of Exclusivity**

Examples like the fediverse servers, some of which either don't federate at all or only have very limited federation (like certain Japanese servers), demonstrate that exclusivity is an option. The current server with its 600,000 users could remain its own entity.

**Empowering Users**

What if we transferred management of the current server to its users? Bluesky the company would continue to develop software for both this specific instance and the larger network. Users could vote and select a management team for technical and trust/safety issues. Digital democracy tools like loomio could be adapted to enable this community governance model, giving users a direct voice in shaping their digital space.

**Funding the Transition**

Running Bluesky costs money, so funding will be essential. Possible sources include Bluesky LLC, crowdfunding efforts, or donations from foundations. Once established, the community could explore sustainable business models to continue funding trust and safety efforts.

**Conclusion**

This approach aligns with Bluesky's original vision of empowering people to run their own communities. By handing over the current server to its users and developing software for both the standalone instance and the larger network, we can support diverse digital spaces that accommodate the needs of all users, while upholding the vision of an open social media protocol.