What's the purpose of the didDoc field in the com.atproto.repo.describeRepo response?

[DavidBuchanan314]

Two questions I guess:

1. What's the response supposed to be used for?

2. Is the PDS supposed to "already know" the value of the did doc (kinda like what getRecommendedDidCredentials does, iiuc), or is it expect it to resolve the DID itself? For example, if an account uses a did:web, and the owner manually edits the DID document, is describeRepo supposed to notice?

[bnewbold]

These are great questions!

This endpoint dates all the way back to the early days of PDS development, when the data transfer mechanism hadn't been designed yet and all accounts were on a single server. I think the original intent of this endpoint was to help simple clients (which don't implement DID resolution) look up other accounts on that server.

My personal opinion is that we should probably deprecate or re-design this endpoint. For accounts local to a PDS (or a relay), there is com.atproto.sync.getRepoStatus for fetching "account hosting" metadata. I've proposed generic com.atproto.identity.refreshIdentity and com.atproto.identity.resolveIdentity endpoint which would work to resolve any identity in the network (regardless of whether it is "locally hosted" either on a PDS or Relay, or even AppView), and to purge caches and refresh. Alternatively, this could be broken up in to separate DID and handle endpoints, instead of combined "identity" endpoints.