-
Notifications
You must be signed in to change notification settings - Fork 56
Open
Description
Goal
As per ipld/js-car#123 we do need a solution for verifying hashes in CAR files without shipping all the MultihashHasher
-s with the CAR library.
Proposal
- Introduce backwards compatible change to the
MultihashHasher
by introducing second OPTIONALcode
argument to thedigest
method.- If omitted it would default to own
code
. - If different code is passed it would error.
- If omitted it would default to own
- Rename
MultihashHasher
interface toMultihashHasherCase
and repurpose it for single algorithm use cases. - Introduce multi algorithm
MultihashHasherVariant
interface with the samedigest
method and a method that returns map ofMultihashHasherCase
it's comprised of. - Define
MultihashHasher
as union type discriminated bycode
field.
Here is the the sketch:
interface MultihashHasherCase<Code extends number = number> {
code: Code
digest(bytes: Uint8Array, code?: Code): Digest<Code>
}
interface MultihashHasherVariant<Code extends number = number> {
// We define `code` as optional which can never have a value. This will allow
// us to `code` as a discriminant in the union
code?: never
cases(): Record<Code, MultihashHasherCase<Code>>
digest <CodeCase extends Code> (bytes: Uint8Array, code?: CodeCase): Digest<CodeCase>
or <Case extends number> (hasher: MultihashHasher<Case>): MultihashHasherVariant<Code|Case>
}
type MultihashHasher<Code extends number = number> =
| MultihashHasherCase<Code>
| MultihashHasherVariant<Code>
Note that above makes current MultihashHasher
-s compatible with proposed MultihashHasher
type that is to say code that will require new type will accept all existing hashers without changes to them.
- With such a type in place
js-car
library would be able to requireMultihashHasher
parameter in order to be able to verify digests. - Added
MultihashHasherVariant
would allow composing many hashers into one.
Metadata
Metadata
Assignees
Labels
No labels