That post is very misguided.

First of all, he’s saying “you SHOULD make your PDS invisible to the bluesky servers because otherwise what’s the point”, but that’s exactly equivalent to saying “our community want it’s own Mastodon server - that means we MUST defederate Mastodon.social or what’s the point?”

That’s nonsense. Don’t enforce silos on people.

Also, which relays to support are not chosen by users, it’s chosen by the services the users choose. The PDS choose which relays to sync to, the appview does too, just like feed generators and moderation labelers does. They can trivially sync to multiple.

What people will choose is what app to use. This app will choose default appviews, and that appview chooses a relay, etc. Then they register an account, and the app suggests a default PDS server, or they host their own.

Also moderation labelers can be shared. Communities can run their own, and different communities who trust each other can import labels generated by the others.

Hosting a PDS is very cheap, it’s just storage and bandwidth for the posts multiplied by the number of relays you directly sync to. With a few users on each that’s nothing. It’s in the range of free tier VPS hosting, RPi grade.

Deduplicating is probably the most trivial part. There’s already code for handling duplicate events in streams. But more practically speaking, there’s algorithms like set reconciliation which can make it significantly more bandwidth efficient to subscribe to multiple relays even when they have overlapping content.

Tldr no there won’t be bubbles, unless that’s what the users want. They surely CAN choose services which filter out the bluesky servers and which don’t make them visible to bluesky, but why?

As for the DID part, the alternative is DID:Web, which requires permanent control over your domain name. With DID:PLC you can control your data by registering your own keys, although there’s possibility for censorship. Their goal is to separate out running the DID:PLC service to an independent foundation.

As for the followup comments, just a few months ago bluesky made it significantly cheaper to authenticate jetstream events via Merkle tree diffs (jetstream is the lower bandwidth version of the relay firehose service). This means you can verify correctness quickly just by having a copy of the Merkle root hash & pubkey for the accounts you’re interested in, you don’t need to store the whole user repositories (excellent for feed generators and moderation labelers and anybody else doing partial sync)