So, a while ago, I wrote a post called “Key Management, ATProto, and Decentralization” in which I complained about ATProto’s approach to decentralization. Since then, Blacksky has spun up an AppView, which makes it theoretically possible to have an actually decentralized experience on Bluesky. This was my line in the sand, stated many times; I would make an account when and only when it was possible to do so without using anything running on Bluesky-the-company’s hardware.
So, today, I tried that. Let’s walk through the process:
Set up the PDS software on a server I control. Because I use NixOS, this was basically trivial.
Create a did:web. This means creating a public-private keypair; I initially tried following this tutorial from Mai Lapyst, but it’s very out of date, and doesn’t include a critical step, as we’ll see.
With that did:web, upload the did.json document to my webserver and set the appropriate DNS entries. Easy enough, except that I also had to set the CORS header for the did.json.
Create an account on my shiny new PDS. I was able to get an invite and create an account, but it was in the “deactivated” status, and I couldn’t activate it. It was very frustrating, because I was making requests manually with curl and reading the error outcomes in the PDS’s logs on my server.
Oh, and by the way, none of this is documented. Sure, the individual endpoints are - kind of - but the only place the whole process is collected in one place is in the comments to this GitHub issue… which is closed as WONTFIX.
Seek help in the ATProto Touchers Discord server, and at their advice delete the account (foreshadowing!).
Start over and re-create everything from scratch, finally noticing the comment line in the comment on the closed GitHub issue telling me to replace the public key in my DID with the public key from getRecommendedDidCredentials.
The documentation for that endpoint, by the way, reads in full:
Describe the credentials that should be included in the DID doc of an account that is migrating to this service.
Note that I am not “migrating”; this account is new. Plus, the JSON keys it returns are almost, but not quite, the same as those in a DID document, and the key it returns actually has to be edited by hand in order to be usable.
Update the DID document with the correct key.
Log into Bluesky (bsky.app) and see the brave new world of… never mind, I get a “Profile does not exist error.”
It was at this point that I found this GitHub issue, which seems to imply that, since I deleted my (completely empty and unused) account, my did:web is blacklisted from the remaining mostly-centralized bit of the system, the AppView. The term for this, apparently, is being “burned”.
Asking in the Discord again, I was told as much, and that my best bet is to reach out to support. Support from the company that I am supposedly free from using. Ugh!
I feel that this completely vindicates my view in my other post that asking users - even pretty technical ones - to handle their own PKI without any tooling or even really any documentation is completely untenable. As a long time Fedi admin friend of mine said, this is somehow harder and more error-prone than setting up a Mastodon instance in 2017 - and you expect each and every user to choose between this and centralization?
ATProto may be decentralized, but Bluesky - the social network and social protocol on top of it - is not, at least not in a way anyone can actually use.
If you’ve been drinking the coolaid, ask yourself this: why is a centralized “burn” able to completely prevent me from interacting with people using Bluesky?
It’s no secret that I don’t like ATProto, but I do actually want to use Bluesky. I find Blacksky really interesting, and I have several friends who post exclusively there. I would love to use Bluesky, with my own domain name, from my own PDS, but I’m not allowed to - because of a centralized authority.
You may be aware that Mastodon has a similar system. If you set up a Mastodon server and then delete the database, anyone you’ve already federated with won’t federate with you again, because you can’t prove you’re the same instance. It’s a genuine issue - but it wouldn’t have resulted in this, because I hadn’t even made a post on my now-burned did:web identity, nor followed anyone.
Even if I had, though, that would have burned a connection, not all connections. My experience would be degraded, but not ruined, and I could work with the admins of the affected servers to remediate it. You could say the same here, of course; maybe (maybe) support will get back to me some day, but it’s just that - support. There is only, really, one connection that matters; maybe two, if you count Blacksky, but their AppView is not generally available yet.
That’s centralization. I don’t understand how you could call it anything else.