Hacker News new | ask | show | jobs
by cryptonector 3127 days ago
Well-designed protocols generally include algorithm identifiers. It doesn't mean that upgrade will always be easy though.

I really don't like given this a new name ("multihash"). We have a name already: algorithm agility. We should use that name.

I also don't like this idea of having a standard for algorithm agility for hash functions (and another for encryption algorithms, and...).

It's also not obvious that making every hash/MAC/public key payload carry an algorithm ID is the right design for every protocol (it's not), though for git it is.
1 comments
benjaminjackman 3127 days ago
Yeah this came out of the IPFS camp, might be sensible though to use the same numeric id numbers for the hashing algorithm ids though all other things being equal.

Generally, and this is just my gut feeling, I think that for any hash code written to disk or stored in some way having an identifier for the hashing algorithm used is such a common bite you in the ass later thing that it makes sense to always just do it from day one. To that end it’s easier to do day one if everyone agrees to a standard set of numeric codes.

Multihash is the standard set of numeric codes for different algorithms I am aware of.

Unifying here might allow git objects to be served natively over IPFS.

link
whyrusleeping 3127 days ago
Just a quick note, while we still would really love to have git use multihash. You can already serve git objects natively over ipfs via: https://github.com/magik6k/git-remote-ipld

Which uses our new plugin system: https://github.com/ipfs/go-ipfs/blob/master/docs/plugins.md

link
lgierth 3127 days ago
> Generally, and this is just my gut feeling, I think that for any hash code written to disk or stored in some way having an identifier for the hashing algorithm used is such a common bite you in the ass later thing that it makes sense to always just do it from day one. To that end it’s easier to do day one if everyone agrees to a standard set of numeric codes.

Yes, that's the basic idea of all multiformats: "it's never gonna change" is considered harmful.

> Unifying here might allow git objects to be served natively over IPFS.

IPFS can already do that thanks to the CID format: https://github.com/ipld/cid

There's no good examples for Git specifically yet, but there's a good bunch of working code for transporting e.g. Ethereum and Zcash transaction blobs over IPFS. For Git it's in principle the same: import the raw object into IPFS, and starts addressing it with /ipfs/<git-cid><original-git-hash>

link