Some quick follow-on thoughts:

• there is always a question of multiple or single/primary linkage. I don't have super strong thoughts but it does always come up and a clear answer/semantic would be good
• DIDs are URIs, so they can be stuck directly in to alsoKnownAs lists. if you do that, you don't know the semantics of the DID when just looking at it, especially if there are multiple. In theory any/all DIDs could be resolved and the DID documents inspected to figure out what they support, but some DID resolution takes time and can fail, so it is nice to skip or only do one if possible. as a motivating case, consider viewing a list of dozens of accounts and wanting to render a badge for ones which have a linked DID for specific other protocol.
• one possible pattern is to use a service identifier fragment like did:web:blah.example.com#atproto_pds: that gives you the DID itself, and you also know it is being included specifically to reference atproto, or a specific service
• another pattern we use in atproto is that you can use an AT-URI, so at://did:web:blah.example.com; that also communicates "we are talking about an atproto identity/account", not just any DID (but the DID is still there and can be parsed out)
• for atproto specifically, displaying handles is user-friendly, but requires an extra step of bi-directional resolution

Great points @bnewbold, thank you!

To start, for just the identity mapping plumbing I think I can punt on multiple vs single and handles for now, just use AP actor ids and ATProto DIDs, and leave the Webfinger addresses and handles to the client(s).

re "what is this DID?", great point. fragment is ok but a bit awkward, at:// URI makes more sense to me at least, I'll probably go with that.

The at:// URI with DID makes the most sense to me too. Update propagation on fedi is not expected to be entirely reliable and the PDS could change, so in my eyes it's better to use the most stable identifier available here, even if the association is not necessarily permanent.

Done! We now add native protocol user id to alsoKnownAs in AP actor objects and new DID docs. Example AP actor objects:

• http://fed.brid.gy/snarfed.org

  "alsoKnownAs" : ["https://snarfed.org/"]
  

• https://bsky.brid.gy/ap/did:plc:thla4qzh7jjzzs6alhih2swk

  "alsoKnownAs" : ["at:/did:plc:thla4qzh7jjzzs6alhih2swk"]
  

Backfilling existing DID docs is a separate question, low priority but I can try to get to it eventually. I've added it to #1014.

Example DID doc: https://web.plc.directory/did/did:plc:skzzh3r474qvgy2llwmt7wp6

  "alsoKnownAs": [
    "at://lawrenceevalyn.zirk.us.ap.brid.gy",
    "https://zirk.us/users/lawrenceevalyn"
  ]

Ugh, looks like this is causing interop issues with some fediverse software: https://git.pleroma.social/pleroma/pleroma/-/issues/3336