feat: support v0 identity cids

[achingbrain]

When dealing with PeerIDs we commonly encode them as v0 CIDs using base58btc encoded multihashes with the identity hash.

The change here is to support 1 prefixed CIDv0 as a special case (e.g. the identity hash) similar to how we support Q prefixed CIDv0 as a special case (e.g. sha2-256).

This lets us parse and validate peer IDs out of multiaddrs, among other things.

Fixes #90

[aschmahmann]

PeerIDs are not CIDs by spec https://github.com/libp2p/specs/blob/master/peer-ids/peer-ids.md, https://github.com/multiformats/cid.

CIDv0 is always DAG-PB and sha2-256 (and encoded as base58btc).

Conflating these specs may lead to user confusion here. In go-libp2p peerIDs are defined as a separate type (i.e. https://github.com/libp2p/go-libp2p-core/blob/525a0b13017263bde889a3295fa2e4212d7af8c5/peer/peer.go#L172 vs https://github.com/ipfs/go-cid/blob/979bf3fb8572224c2b2fbfaf153f94b98734807c/cid.go#L243)

What's wrong with using https://github.com/libp2p/js-peer-id/blob/master/src/index.js?

[achingbrain]

PeerIDs are not CIDs by spec

Hmm: https://github.com/libp2p/specs/blob/master/RFC/0001-text-peerid-cid.md

The peer-id module carries a lot of crypto baggage with it that makes it unsuitable for use in the http client as it's too large, to the point that we don't use it in the http client, only in in-process or daemon js-ipfs/js-libp2p.

For whatever reason we decided instead to pass peer IDs around as CIDs as a 'lighter weight' version of peer-id so it has methods to convert to and from a CID (v0 identity or v1 libp2p-key).

Maybe it shouldn't but that's a much bigger scope change than upgrading multiformats to get the new @ipld/dag-cbor @ipld/dag-pb module goodness.

All this PR really does is add a feature that was in the cids module but is missing from this one.

[aschmahmann]

Hmm: https://github.com/libp2p/specs/blob/master/RFC/0001-text-peerid-cid.md

This is a spec detailing how to encode peerIDs as CIDs in text, which is a subset of the peerID spec (e.g. peerIDs are represented as multihashes, not CIDs, in byte encoding and peerIDs are also representable as base58btc multihashes in text).

All this PR really does is add a feature that was in the cids module but is missing from this one.

🤷‍♀️ if the previous implementation (js-cid) wasn't spec compliant and the idea is you want to make this one match the other one then I guess that's up to you + others familiar with the js codebase. You should probably file an issue then to make a peer-id type that you can use so that you can make the CID type spec compliant again.

[rvagg]

Weird, I didn't know this was a thing. As @aschmahmann says this is not in the spec, it's explicitly always a sha2-256: https://github.com/multiformats/cid#cidv0

the multihash is written as is but is always a full (length 32) sha256 hash.

go-cid is pretty explicit about this: https://github.com/ipfs/go-cid/blob/979bf3fb8572224c2b2fbfaf153f94b98734807c/cid.go#L646-L667

js-cid explicitly won't let you turn a CID that isn't sha2-256 into a CIDv0: https://github.com/multiformats/js-cid/blob/13647819ec1256bab6bd0e885a304d74bce138d6/src/index.js#L242-L244

It doesn't look like this was completely intentional in js-cid either, it just hands off to multihashes to decode whatever's there and assumes it's going to be correct: https://github.com/multiformats/js-cid/blob/13647819ec1256bab6bd0e885a304d74bce138d6/src/index.js#L125

This means that you can even do silly things like this:

c = new CID('Yn1VgDzJSXCEaTcxeUfKdU13EeQrF1VHCjLDbTFntRtQQmHF4WZVjUCC')
> c.version
0
> c.multibaseName
'base58btc'
> c.codec
'dag-pb'
> multihash.decode(c.multihash)
{
  code: 45584,
  name: 'blake2b-128',
  length: 37,
  digest: <Buffer 08 02 12 21 03 36 7f 38 08 9c 1b aa 2b de 5e 58 f7 0c 49 09 7a 9b 16 af 46 33 c2 cd 9a 32 c1 03 9d 5d 05 6c 65>
}

I could do PJ3dBWyYd2N1bUNvCzrWGGCeQXn45H4bohbCdeVWYXXoCyc1a16Sx as a murmur3-128 CID and even 8G7hRq6CZgo2Z3seEjHYf2mfGPHJQJdDSk3HXVLRasRAQWRNPukTaeY as a sha2-256-trunc254-padded Filecoin CommP hash CIDv0. I can even do new CID('4jdwdZ') for a single zero byte sha2-256-trunc254-padded dag-pb CIDv0, fun fun! But.. probably not correct.

How much pain would there be in removing CID from the Peer ID path? Can they just be a multihash instead? Or is it tightly tied up in the system? This seems to be one of those things that was done because it happened to be possible in the code, but it probably shouldn't have.

[achingbrain]

Wild. Anyway this shouldn't be merged as a string v0 identity CID isn't a CID, it's a multibase encoded multihash with the identity multicodec so we shouldn't treat it like a CID. Phew.

How much pain would there be in removing CID from the Peer ID path?

I think most of it would be swapping out use of PeerID.createFromCID for PeerID.createFromB58String and constraining the input types accordingly - we seem to pass strings into createFromCID as the js-cids constructor supports that when we should really be using the other method.

I don't think we can remove .createFromCID entirely as from https://github.com/libp2p/specs/blob/master/RFC/0001-text-peerid-cid.md we can expect to encounter Peer IDs as strings of v1 CIDs with the libp2p-key codec, so we'd create a CID from the string, then a PeerID from the CID.

[Gozala]

The peer-id module carries a lot of crypto baggage with it that makes it unsuitable for use in the http client as it's too large, to the point that we don't use it in the http client, only in in-process or daemon js-ipfs/js-libp2p.

We should probably address this