ID design and replaceability

[yamarten]

I am looking forward to the future where the ATP account is my representative ID, but did:plc seems unstable, and did:web needs to maintain server forever (and there is no way to use it now). So I have several questions about the ATP identity system.

1. did:plc seems to be a DID method that uses verifiable logs and unreliable resolver to avoid slow distributed ledger. On the other hand, did:oyd and did:keri are more general DID methods with similar concepts. Why did you create an incompatible new method instead of these subsets?

2. Are you planning to provide a method to verify the domain name change? For example, as a simple and incomplete method, a short hash of a DID that can be printed alongside the domain name. (ref. I've trouble understanding security in DID migration #279)

3. Are DIDs permanent? In other words, is it possible for users who select did:plc to change to other DID methods in the future (in a way such as alsoKnownAs redirection)?

[bnewbold]

Old questions, but still relevant.

1. did:plc is more stable these days, and works in a reasonably general purpose way. We have iterated on the implementation (in a backwards compatible way), registered in the W3C registry, and are not calling it a "placeholder" any more (though we are still open to assessing other methods). I don't think we were particularly aware of did:oyd and did:keri when designing the identity system last year, though we did review a lot of the other DID methods.

2. I think our handle specification has been firmed up and answers this question: https://atproto.com/specs/handle

3. DIDs are permanent, in that they are referred to in AT URIs and need to keep resolving indefinitely. It would make sense to have a way to migrate from one DID to another, at least as a rare/infrequent event, and that might work as an AKA pointer. There is some interest from other orgs in standardizing a way to migrate DIDs from one method to another, we'll probably wait and see what comes out of that.

[yamarten]

Thank you for answering!

I agree with 1 and 3, but I still have questions about 2. My main concern is that DIDs are completely hidden, so references from outside atproto, such as the account pointed to by the https://bsky.app/profile/atproto.com link, can change depending on the access timing. The same is true when using handles in at-uri.
I know you can use the DID in URLs, but they're not often seen by users and probably won't be used due to the low readability of DIDs. URLs printed on paper are especially prone to this problem because they want to be easy to read and difficult to update.

Is it possible to create an optional mechanism that can detect DID differences without impairing the convenience of the handle? I believe it's based on a similar philosophy as getRecord can specify a CID in addition to the rkey.

[bnewbold]

There are definitely real concerns and tensions about when to use DID vs. handle in AT URIs and web URLs. DIDs are persistent but not (for did:plc) human-friendly; handles are (usually) recognizable and can have semantics, but can change over time.

The specs usage guidelines discuss best practices a bit: https://atproto.com/specs/at-uri-scheme#usage-and-implementation-guidelines

The URL example you give could also change based on who controls bsky.app at any point in time. Institutional infrastructure domains (like bsky.app) may or may not be more durable than individual identity domains. bsky.app is specifically tied to a single company and application also, there might end up being an alternative infrastructure domain for inspecting and referring to atproto records in general (or maybe AT URIs would get more general public adoption).

It would be great if there were URLs which encoded long-term persistent identifiers and were human meaningful and were reasonably short. I don't see a solution to all of those needs at the same time. It would be possible to have URLs like:

https://atproto.example/did:plc:ewvi7nxzyoun6zhxrhs64oiz/handle.bsky.social/bsky.app.feed.post/3k4duaz5vfs2b/bafyreibjifzpqj6o6wcq3hejh7y4z4z2vmiklkvykc57tw3pcbx3kxifpm

That's got it all! But it's also 163 characters long.

[snarfed]

Great conversation! Zooko's triangle is obviously very relevant here, as always. Secure, decentralized, human meaningful: choose two. (With lots more nuance, obviously.)
https://en.m.wikipedia.org/wiki/Zooko%27s_triangle