unable to resolve DID document's short URI after reigisting and publishing it in ION chain

Question

My problem is that I am unable to resolve the Decentralized Identify (DID) document using short-Form URI after publishing it to ION chain. Thanks if you can help correct me or some suggestion.

A sample code

import { anchor, DID, generateKeyPair } from '@decentralized-identity/ion-tools';

// Generate keys and ION DID
let authnKeys = await generateKeyPair();
let did = new DID(..);

// Generate and publish create request to an ION node
let createRequest = await did.generateRequest(0);
//anchor: post and publish DID document to https://beta.ion.msidentity.com/api/v1.0/proof-of-work-challenge
let anchorResponse = await anchor(createRequest);
console.log(anchorResponse) 
let uri = await did.getURI();
let shortURI = await did.getURI('short');
console.log("Long URI "+ uri+ "\nShort URI: "+ shortURI);

This code is nearly copied from Readme.md in https://github.com/decentralized-identity/ion-tools. The method anchor()at the bottom posts and publishes the request to ION chain, which is L2 for bitcoin chain. After execution, both short URI and Long URI are print, in which the short URI is only resolvable after it is published.

Previously, both Short URI and Long URI can be resolved in both https://identity.foundation/ion/explorer and https://dev.uniresolver.io/. I can get a fully defined DID Document from registry. But the resolve fails and returns 404 since 28 July.

My understanding is that the short uri should also be resolved to the specified document as the long URI.

Here are two screenshots:

Answer 1

The short DID cannot be resolved until anchoring of the DID document has been complete. Because the Sidetree protocol uses batching and there is latency in writing to the blockchain itself, this can take time.

When you present a DID (long-form or short-form), the resolver will check to see if the document has been anchored and if so, it will use the address information in the DID to get the full document.

If the DID document is not yet published, it can decode the suffix of the long-form DID to construct the DID document and return it since the suffix contains all of the original service and verification method information. Of course, the suffix is missing from the short-form DID so this unpacking cannot happen.

If you resolve a long-form DID, look at the didDocumentMetadata section of resolution response you can see a flag that indicates whether or not the document has been published.