sidetree
sidetree copied to clipboard
Equivalent ID proposal and inferential version pointers
@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.
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.
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
.
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
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
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.