Handle identifier specification

[bnewbold]

Hey folks!

We are working through more detailed specs for the atproto.com website.

The first PR for this work, documenting the details of the "handle" identifiers is in review here: https://github.com/bluesky-social/atproto-website/blob/f3ecafc36c1ce8c78c4b348edbc4cbd580274f24/content/specs/handle.md

EDIT: now live at https://atproto.com/specs/handle

Details on handle resolution will be specified separately. Similar docs for other identifiers (NSIDs, AT-URIs, DIDs, and Record Keys) will be rolling out, as well as details of the repo storage format and MST.

[snarfed]

This is awesome! Thank you for writing it up.

As a spec for handle identifiers themselves, this is clearly very comprehensive. I'm looking forward to a number of other closely related things:

• How domain handles interact/coexist with did:web
• How much of the DNS <=> DID doc validation is part of AT Proto vs left as PDS implementation details
• How that verification works with federation, synchronizes (or doesn't) across PDSes, guidelines for UX display if handles are eventually consistent across federation (which I expect), etc
• Guidelines for dealing with handles stored in records inside PDSes, since they'll inevitably get out of date and skew with their DIDs' current handle(s)
• Future plans for multiple handles per DID

None of this is urgent, obviously. Thanks again!

[bnewbold]

Yup!

A next piece of work here is specifying the "handle resolution" process via DNS TXT record or the HTTP(S) /.well-known/ method. And, in particular, all the various corner-cases if there are conflicting results between those two, if the DID document doesn't match, when to cache and how long, when to use recursive DNS lookups, etc.

A couple quick/partial answers to your questions:

• domain handles and did:web are confusingly similar, but for now we treat them as entirely distinct things. A did:web account can use a totally different hostname as a handle.
• There are some other restrictions on did:web, like you can't use ports (with hex-encoding) in most cases, and "sub-path" DIDs aren't supported, only full-domain DIDs
• we will try to give specific guidelines on handle/DID cross-validation, and details of how to extract atproto-relevant bits from a generic DID document (regardless of the DID method used; though TBC there are only the two "blessed" DID methods of plc and web right now)
• w/r/t handles in records, the general advice is to use DIDs instead of handles as much as possible when persisting, and only use handles for display. we will touch on this a bit in the updated AT-URI doc, as AT-URIs can have both DID and handle forms, and you might want to use different forms in different contexts. but generally handles are weak refs, and DIDs are strong refs
• multiple handles per DID: probably after full federation launch, in terms of priority. we might try to mitigate the most common issue which is when somebody wants to reserve <twitterhandle>.bsky.social (or whatever base domain is being provided) but also make their actual handle an independent domain. we think with federation and multiple base domains floating around the desire to "reserve my username!!!" will be even further reduced though

[snarfed]

Thanks! This pretty much all makes sense.

• AT-URIs can have both DID and handle forms

Whoa! This is news to me. I know the bsky.app web frontend has handles in URLs, but I didn't realize at:// URIs could too.

[bnewbold]

Here are the updated AT-URI specs (note the domain this URL: it is a PR previous, not (yet) the official atproto.com website):
https://bnewbold-specs-at-uri.atproto-website.pages.dev/specs/at-uri-scheme