Rationale:
- been around since the very early days, seems we just never added it?
- we already have dnsaddr, which works similar way, but for multiaddrs (TXT records)
- we want to support IPNS-agnostic recursive TXT values `dnslink=/dnslink/example.com`
- we need a way for pinning DNSLink names within Pinning Service API
This is an ongoing pain-point because it serves as an example of the very weird edges of the multicodec table. I'm not aware of any real use; or even how it could be practically used. It's not a "hash function", but describes a hash process that needs additional "function" information. I suspect it has its genesis in looking at Bitcoin et. al., but for those binary merkle trees we use `bitcoin-tx` coupled with `dbl-sha2-256` which gives us all the information we need.
`ssz-sha2-256-bmt` is a newer example of an entry that's more descriptive, it stretches definitions a bit here but describes a hashing process within a format. It's probably not an awesome example either, but it's closer to a standard (current) understanding of multiformats than `bmt` is (not just because it can actually be implemented and used).
Can anyone think of a good reason to keep this entry, or can we remove it as cruft?
SM2 is a set of cryptographic algorithms based on elliptic curve cryptography, including a digital signature, public key encryption and key exchange scheme.
The ISCC is similarity preserving identifier for digital content. An ISCC is derived algorithmically from the digital content itself, just like cryptographic hashes. However, instead of using a single cryptographic hash function to identify data only, the ISCC uses a variety of algorithms to create a composite identifier that exhibits similarity-preserving properties (softhash). For an implementation of code `0xcc01` see: https://iscc-core.iscc.codes/#quick-start
See
https://docs.softwareheritage.org/devel/swh-model/persistent-identifiers.html
for the technical details of that spec.
Software Heritage has done a superb job promoting content addressing in
general, and their identifier scheme (SWHIDs, for short) in particular.
By supporting them in CIDs / IPLD, I hope the IPFS ecosystem can align
itself with that effort.
Per the linked documentation, SWHIDs have their own nested grammar and
versioning scheme. I begun by taking the version 1 core identifier
grammar, unrolled it, and replaced `:` with `-` per the guidelines on
separators, with the result being these 5 rows.
There is overlap between the remaining for and git-raw, so this just
adds SWHID snapshots for now.
Add eth-receipt-logand eth-receipt-log-trie types
Also:
* Clarify ETH "block" terminology, as it is actually only the header that is hash referenced by "block" hash and the header in turn contains all the roots to the tx, rct, state (and thereby storage) tries.
* Changed "RLP" to MarshalBinary in the description for tx and rct, because after EIP-2718 tx envelopers were introduced the consensus encoding of a tx or rct is only the pure RLP encoding for the legacy types.
This makes it clearer that there doesn't necessarily be an official standard,
but having wide adoption and being a de-facto standard could still be enough.
