Hacker News Reader

Comment by stebalien | Hacker News Reader

The recommendation to resolve from handles to DIDs for "permalinks" is concerning to me:

- My handle is something _I_ control. I can make it point at a different PDS at any time.

- My DID is something my PDS controls.

I could solve this by indirecting through a web DID under my control, but there's no recommendation anywhere in Bluesky's documentation. Is that something everyone needs to do to ensure real identity portability?

edit: I'm not sure this CAN be solved without running a PDS given that I can't use my own keys. What am I missing here?

View on HN

This doesn't look right to me.

What you control is your identity (i.e. DID Document). As long as you control your identity, you can change either your handle or your hosting aka PDS.

Your hosting/PDS does not control your DID.

What stebalien might be referring to is that your DID document for PLC specifically is controlled by anyone with the rotation key.

In the Bluesky implementation, this is Bluesky for convenience’s sake, to make it possible for users to easily sign up. (I’m not sure internally if it’s part of the PDS or held separately.)

PLC has a mechanism allowing “higher” keys to override “lower” ones within a certain time window, so being able to add your own rotation key that “outranks” Bluesky’s would solve this issue.

Alternatively, use web DIDs and then it’s fully self-managed just as DNS would be.

Is there any documentation on how to do this without running a custom appserver and/or PDS? Can I create my own DID and delegate to another DID?

This is mostly separate to the PDS - Bluesky is more like the client here (albeit, they also currently run the PLC service). It’s part of your DID document which they manage for you mostly, but there’s ways to take ownership of your PLC DID - see Dan’s links for that.

For our non-atproto uses of the PLC directory, we have similar needs, and we’ll likely let users provide their own public key before we create their document to help solve this. We have a technical audience though, so that solution may not make sense for Bluesky - but there’s a lot of people thinking about how to improve this in the atmosphere.

Ah yes, this might be relevant then: https://www.da.vidbuchanan.co.uk/blog/adversarial-pds-migrat...

I control my domain name and its DNS but I don't have the keys used to sign my DID. I followed the instructions here: https://bsky.social/about/blog/4-28-2023-domain-handle-tutor...

From my reading of your blog post, it sounds like the DID is the ultimate authority and not my domain name, which sounds like a pretty big problem for user portability.

Right, I see. You can get a key that overrides your PDS if you're worried about your PDS going rogue. See https://www.da.vidbuchanan.co.uk/blog/adversarial-pds-migrat... and https://whtwnd.com/bnewbold.net/3lj7jmt2ct72r. This is more complicated than I'd like it to be.

Ah, that's exactly what I was looking for. Thanks!

I guess I get why it works that way (avoids some issues with domain expiration) but... honestly, I'd rather have my domain name in control. Even after registering my own rotation key, I'm still at the mercy of the centralized PLC directory.

Unfortunately, it looks like it's not possible to migrate to a web DID without starting over.

So the reason to have the DID in control is for users that say sign up for Bluesky and have a bluesky handle which is a domain they don't control and want to move to a different provider without breaking everything. If your handle was the thing in control then you must own a domain to own your account and move providers. That kinds of defeats the purpose of migratable PDSs for the "rest of us" use case.

Yeah, you can't migrate a DID. You could bulk-import the content (and even fix internal links within it) but that wouldn't change the links pointing at the old DID.

Reply on news.ycombinator.com