Migrating from did:plc to did:web

[TCFox]

Hi folks!

I've signed up for Bluesky a while back in the past, but am really interested in the idea of hosting my identity in a more decentralised manner (largely for geek-cred than anything else). This may or may not also involve running my own Bluesky PDS for personal use.

While migrating to a new PDS is a challenging but supported task, is it also possible to migrate my current did:plc identity to a did:web identity either separately or at the same time (while keeping my handle the same in all cases)?

My current understanding is this is likely impossible, given it's the identifier for my account, and other relationships (such as followers) will suddenly lose track of me. But I'm unsure if those relationships actually track my handle rather than my did identifier, or if there is some sort of "pointer" mechanism built into the did:plc document specification that could facilitate any relationships between data that still uses my old did:plc identifier.

If it's definitely not possible, what are the consequences of moving my handle from a did:plc identity to a different did:web identifier? Is there any way I can limit the amount of "breakage" while moving between these two identities (particularly in the context of Bluesky itself)?

I'm keen to hear what might be possible!

[DavidBuchanan314]

My current understanding is this is likely impossible

Yup, that's pretty much it. You can keep your handle and point it at your new DID, but all in-protocol references are based on the DID. You will lose your followers, for example (because they're "following" your DID, not your handle).

You could in theory re-import your old posts, but they'd lose any existing replies/likes/etc., and any threads would be broken.

I might do a similar migration myself at some point, and if I do, here's what I'll do:

1. Migrate the did:plc account to my own PDS.
2. Create the new did:web account, also on my own PDS.
3. Change the handle on the did:plc account to a "legacy." subdomain or something, and move the original handle to the new account.
4. Set up automated ~daily posting on the did:plc account to say "hey I've moved to [did:web account], please follow me there instead"

It's useful to keep the did:plc account around, both as an archive of old posts (preventing dead links), and as a way to direct people towards the did:web account. Notably, I don't plan on trying to import old posts - seems like more trouble than it's worth.

Things like follows, blocks, custom feeds, mutes, preferences could be migrated fairly seamlessly though - I wonder if anyone's made tooling for that.

[swcurran]

The did:webvh implementers guide outlines our approach to DID portability, which aligns closely with @bnewbold's comment. We consider the prefix to be the stable identifier, while the inclusion of the domain/path enables straightforward discoverability. For DIDs that never relocate, this works seamlessly — and did:webvh allows for a DID Controller to prevent ever porting their DID. However, for DIDs that do move, our portability design retains the prefix and the verifiable history of the DID, reflecting the decentralized trust model of the Web.

The portability approach was heavily influenced by use cases like Bluesky’s. In this model, a service provider (e.g., Bluesky) could host the DID and provide services like social media, email, chat, or file hosting, utilizing the user’s keys published in the DID. If the user decides to migrate to a new service, they could carry their DID's SCID and history to the new location. This ensures that verifiers can trust that the same entity controls the DID post-move.

This contrasts with the current scenario where users must inform their contacts of new service addresses (e.g., “Hey everyone, I’ve moved from Gmail to Yahoo and here is my new email address. Really, it's me -- honest!!!”). With did:webvh, the move would be cryptographically verifiable: verifiers could check SCID/log entries to confirm the change, maintaining continuity and trust. Ideally, a service provider like Bluesky could implement resolution redirection for the “old” DID to its new location when a did:webvh moves, enhancing user experience and trustworthiness. extending the lifetime of the original DID.

We also borrowed features from did:plc to enhance usability and security, such as allowing multiple keys to authorize updates. This enables a trusted service provider to assist in managing the DID when necessary. Additionally, our witnessing mechanism could support confirm-before-update features, complementing the design philosophy of did:plc.

Happy to collaborate / discuss further.

[bnewbold]

From the standpoint of atproto:

• the DID is a permanent account identifier. accounts are one-to-one with an exact string. the string can not change, in part or in whole
• every server on the internet should be able to rapidly resolve a DID, and to some degree everybody should see the same result. caching is allowed, but should not be required. that is, a brand new server just installed today should have all the same info a 5-year-old server. servers are not expected "store" identity information (aka, should not have lookup or mapping tables internally)
• the DID method needs to describe how to resolve any DID with the method prefix

did:webvh is interesting. If it got a lot of independent adoption, or full standardization by the W3C, maybe we could at least partially support it. I think the way that would work is that it would be basically did:web with an oplog, but migration would be not supported: a new domain would mean an entirely new DID from the perspective of atproto, and things like social graph (following) and post threads would not be migrated (you'd be starting over with a new account). But this is still arguably better and more secure than did:web: there would not be the confusion of a did:web account changing hands and suddenly you are "following" an account controlled by a different party.

did:dht is interesting and maybe could work, for atproto, but there have been many DHT projects in the history of decentralized computing, and only a small handful have really worked out. AKA, been resilient to abuse, attacks, neglect, etc, over years and decades. magnet links are cool but kind of the exception to the rule. I think if the W3C standardized did:dht it could be a real contender, but somebody needs to carry the flag and demonstrate it working "in real life" with millions of users, and I suspect that will be difficult, and I would not expect Bluesky to lead that charge (we already have our own pet DID method to maintain and support).

[erlend-sh]

did:dht is interesting and maybe could work, for atproto

There’s some very interesting work being done with DHT by the folks (@SeverinAlexB & @Nuhvi) at pubky:

• pkarr — content addressing and retrieval via DHT.
• pkdns — DNS server resolving records hosted on the Mainline DHT.

[erlend-sh]

pkarr was being used as a fundamental building block in did:dht, which unfortunately appears to be discontinued (afaik this was the org driving it). Even so, @decentralgabe may appreciate the renewed discussion here.

migration [in did:webvh]would be not supported: a new domain would mean an entirely new DID from the perspective of atproto, and things like social graph (following) and post threads would not be migrated (you'd be starting over with a new account).

Doing some of my signature unqualified hand waving, I wonder if pkarr’s ‘sovereign TLDs’ could be used in did:webvh as a permanent domain identifier to work around the lossyness of domain migrations.

[decentralgabe]

did:dht uses the same underlying tech as pkarr, they had the same roots. however, I believe the overhead of DNS packet-style serialization is inefficient, and would like to see did:dht evolve to use dCBOR. @ChristopherA is interested in this too and might have some thoughts here. did:dht has been moved from its prior home (TBD) to the Decentralized Identity Foundation which is quite a friendly org for progressing the project.

I'm happy to help however I can.

[swcurran]

Thanks for the feedback @bnewbold — interesting. In creating did:webvh, we need web resolution as a core feature (it’s in the name, after all…), so having the location in the DID is pretty important. Further, the web changes over time, and so allowing portability is likewise deemed necessary (although it is not required — a did:webvh DID can state it is “not moveable”). Interesting to think about if we could make the DID end at the SCID (globally unique and long-lasting) and use some sort of DID URL mechanism to allow for the location of the DID.

I do think being able to move a DID as done with did:webvh could be a powerful enabler of “credible exit” — being able to take your unique identifier (SCID) and your DID history of keys and key rotations when you move to another service.