nostr:nprofile1qqsfzzhequxl66lwucls6j42cd2ttkskf44my0yusakd75jvwgzwvmgpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsz9thwden5te0dehhxarj9ehhsarj9ejx2a30qy88wumn8ghj7mn0wvhxcmmv9u80rd8x What nostr:nprofile1qqsp77g933m6yf89hc3xerczfjkd44xhgxz46a0dnug5wwagawrwrjcppemhxue69uhkummn9ekx7mp0qys8wumn8ghj7mn0wd68ytn9d9h82mny0fmkzmn6d9njuumsv93k2tcpz4mhxue69uhkummnw3ezummcw3ezuer9wchsdcndl4 said. 

Imagine X published all the source code for running x.com. You could set up your own version at y.com, but nobody who created an account there would be able to follow accounts on x.com, or vice-versa. So there's no point.

That's essentially the situation with ATProto. In theory, you can set up a complete clone of the BlueSky service, but it's totally up to them whether accounts on your service can be seen on BlueSky.

The chokepoint is not the software, it's the ID layer. The fediverse/ ActivityPub tried to solve that by taking a leaf out of the IndieWeb's book, and outsourcing the ID layer to DNS. The Zot/ Nomad branch of the fediverse has always had NomadicIdentity, which makes accounts ("channels") independent of the domain names of servers, and there are a number of FEPs describing how to do that in AP software;

https://wedistribute.org/2024/03/activitypub-nomadic-identity/

Nostr solves the ID chokepoint problem in a similar way, by having a decentralised ID layer. So that's a step forwards from the existing AP+DNS dominated fediverse. BlueSky is a step backwards, and the main reason people use it is the aggressive Safer Spaces Policing that their ID chokepoint allows;

https://wedistribute.org/podcast/blacksky-rudy-fraser/

For some people that's a feature, and a permissionless network is a bug that feature solves. 

 Oh yeah, no, it's very centralized at the moment and even in a perfect implementation it'd still be somewhat more centralized than Nostr. Still, they've made a lot of progress (going from 100% centralized to mostly centralized in a couple months earlier this year). Theoretically, whether you were having X.com or Y.com aggregate data from PDSs, it'd still be the same PDSs so people from X.com could talk with Y.com - assuming no blocking/errors/funny-buisness was going on.

And for the DIDs, you can actually hold your own with your own PDS. Bluesky itself won't hand you your keys yet, although they are planning migrations at some point so they likely will in the future once that side of thing is developed. Probably not ideal for us and our fellow tech nerds, though most people probably won't care or even prefer custodially held keys. 

 "Theoretically, whether you were having X.com or Y.com aggregate data from PDSs, it'd still be the same PDSs so people from X.com could talk with Y.com - assuming no blocking/errors/funny-buisness was going on."

The point is that x.com and y.com have the power to block each other's accounts. So as I say, there's no point setting up y.com. It's much cheaper and easier to set up an AP server or Nostr relay instead. So unless something radically changes in the ID layer of ATProto, it will always be controlled by BlueSky, and it will always be as centralised as Xitter where it matters most.

> most people probably won't care or even prefer custodially held keys

This is like when apologists for Gmail say that most people don't care about runing their own email server. Or when apologists for proprietary software say that most people don't care about reading or modifying source code. Or when apologists for dictatorship say that most people don't care about reading laws or government reports.

It's probably true, but entirely beside the point. The fact that you *can* do it, if you want to, totally transforms the incentive structures.