His takeaways are that "to resist misguided censorship" we need:

- A service with no central choke-points, but rather a large number of independent co-operating nodes.

- Accounts, and the follower relationships between them, are not tied to any single node.

So... Nostr?

Minor note on this post (which was posted a week ago) that bluesky users have just in the last day made their first posts on bluesky completely independently of bluesky PBLLC and its' hosted infrastructure[1].

There are of course some minor caveats to this.

- The accounts use did:plc based accounts which still depends on https://plc.directory for recording updates to certain low level account details (old handles, current handle, cryptographic keys, etc) but given everything has to be signed by the user's keys, if they hold their own keys there's no risk of bluesky manipulating their account. Also isolating this from bluesky PBLLC to a foundation is in progress and further decentralisation efforts will continue.

- Users could opt to use did:web instead but that comes with UX issues (requires your own domain, cannot change the domain ever) so users generally don't do it. Bluesky could also adopt another did format in the future as well.

- Providing a CDN for a social media network and/or serving video and images is really, really expensive. So while 3rd party appviews can user their own CDNs or just host assets directly, in general they will probably just rely on bluesky PBLLC's CDN for cost reasons. Of course this is superficial and can be changed by any appview operator with a flick of a switch.

Otherwise however bluesky at this point is decentralised to the point that should bluesky PBLLC dissapear, the community could move on (ignoring general CDN operation costs which could be dropped if absolutely necessary). It's not the most polished experience and much like mastodon requires a bit more technical effort to be "truly decentralised" but it is very much possible nowadays.

Also just a brief breakdown of what censorship/moderation levers bluesky PBLLC actually has:

- Bluesky moderation service: a global client-side opt-in labeller that just puts metadata on posts

- Bluesky regional moderation services: region local client-side opt-in labellers that just puts metadata on posts

- Bluesky Hosted PDS: Bluesky as a PDS operator can take down/ban users or posts on their PDS but have no power over users or posts on other PDS

- Bluesky Hosted Relay/Firehose: Bluesky can censor/block content coming across their relay but as the relays are gossip based, they can't stop 3rd party relays from gossiping with each other. Sync 1.1 lowers the cost of running a relay to 2 cores, 12GB RAM, 20-30mbps up/down, and anywhere from less than 100GB storage up to terabytes of storage (depending how much history you want to store vs fetch from elsewhere). That fits comfortably on a raspberry pi on a residential internet connection.

- Bluesky Hosted Jetstream: essentially the same as the relays. Jetstream just ingests the CBOR firehose and lets services subscribe to all or parts of the firehose but exported in JSON. But notably this can be self hosted just like relays.

- Bluesky operated https://plc.directory : At most bluesky could censor/hide new changes to accounts via this. This isn't a hard technical limitation but rather functionality to circumvent that hasn't been implemented yet due to triage priorities (i.e. should it be a problem it could be addressed in less than a week or two).

1. https://bsky.app/profile/bad-example.com/post/3loe7iy2gdc2c

------

TLDR: Bluesky PBLLC has exactly one hard lever to moderate or censor the service at this point (and it's very much temporary) however they have multiple soft levers that users can opt out of (or transfer control to other operators/themself).