Equivalent ID proposal and inferential version pointers

[OR13]

@csuwildcat we chatted about this.

• "657372-1286-6394"
• "block_number-txn_number-entry_number"
• did:example:123

You might use a "ledger pointer" to find a "didUniqueSuffix", and then grab "latest version"

You might use a "ledger pointer" to find a "didUniqueSuffix", and then grab the version at that point in time.

In other words, there can be "aliases" for a did document at a version, and "aliases" for the latest did document.

Sidetree does not officially support the version did query param, but we might consider supporting it, and we might consider sameAs / cannonicalId as they relate to other "aliases"....

I would say we need to be careful about saying "old" === "new" in the sense that compromised rotated keys are authoritative for the latest did document.

[csuwildcat]

This did:foo:block-txn-entry form of equivalence can also make it possible to create even more terse, interesting forms of ID representation equivalence, for example: a did:foo:block-txn-entry sequence may contain within it the digits of unicode/emoji characters, meaning you could have an equivalent form of an ID that is something like did:foo::duck: :heart: :bike:

How one might enable such terse forms of equivalence would need far more discussion, but it's valuable to understand that with equivalence we may have a path to the expression of IDs in forms that humans could conceivably remember and use more easily in some use cases.

[csuwildcat]

One form this could take is an ID with segments for did:sidetree:BlockNumber-TransactionNumber-EntryIndex represented in Base36 characters, which would result in case insensitive IDs of this form and maximum length: did:sidetree:abc12-de3-fg6.

[csuwildcat]

One thing to note: because you could map all Core Index File-centric ops to these IDs (Creates, Recovery, etc.), there may be a premium on having your ID ops low in the txn order and low in the op index within the Core Index File. There's a bit of game theory there that may lead to people trying to get very small IDs, given low numbers on both would produce desirable IDs like this: did:sidetree:aaaa-0-0

[csuwildcat]

I had a thought that might make these small ID forms event smaller: technically, you can number every operation in a block, because every transaction has to declare how many ops are inside it. This means that we may be able to create a minimum length form of ID like this: did:example:<BlockNumber>-<AggregatedOperationIndex>, wherein the AggregatedOperationIndex = the index at which an operation falls if you were to virtually flatten all the transactions in a block into a single depth array. This would yield ID sizes (using ION as an example) as short as: did:ion:754321-598764

[troyronda]

In did:orb, once published, we return the canonicalId that includes the anchoring information.

As in:
did:orb:<anchoring CID>:<unique suffix>

Your example is similar in that you are including anchoring information into the identifier. In our case, we have a CID from our IPFS-stored anchor object. In your case, you have the bitcoin block. Both cases are identifiers from the respective anchoring system.

However, I like using : for the separator between anchor id and suffix (or index) - and this is what we implemented.