Publish DID documents per did:web spec

[Peeja]

Per spec:

Creating a DID is done by:

1. applying at a domain name registrar for use of a domain name and
2. storing the location of a hosting service, the IP address at a DNS lookup service
3. creating the DID document JSON-LD file including a suitable keypair, e.g. using the Koblitz Curve, and storing the did.json file under the well-known URL to represent the entire domain, or under the specified path if many DIDs will be resolved in this domain.

For example, for the domain name w3c-ccg.github.io, the did.json will be available under the following URL:

Example 4: Creating the DID

did:web:w3c-ccg.github.io
 -> https://w3c-ccg.github.io/.well-known/did.json

We use did:web DIDs, but do not publish did.jsons. For instance, we use did:web:web3.storage, but don't publish https://web3.storage/.well-known/did.json.

Some of the information which goes in the DID document is information we currently assume we know, because we're Storacha ourselves. But ideally we would fetch the DID document like anyone else, and not depend on two parts of the service (currently) being owned by the same organization and knowing each other deeply.

For instance, we assume that did:web:web3.storage accepts UCANs on https://web3.storage/. But properly, that should be found in the services key of the DID document.

Upshot

• We get to stop knowing the public key of every other service's DID in advance.
• We get to stop knowing the service endpoint of every service in advance (ie, no more NEXT_PUBLIC_W3UP_SERVICE_DID and NEXT_PUBLIC_W3UP_PROVIDER; just the first one is enough).
• Not only is that less well-known info for us to have in advance, it also opens us up a little bit more to work with other hosts who conform to our protocols. Any service with a did:web:*—or indeed any DID we can resolve to a public key and a Ucanto endpoint—can slot into our network.