peer-id questions

[hackergrrl]

Heya! I had some questions about peer id:

1. Is there a spec for PeerId?
2. What is the mandatory API for a PeerId to expose?
3. Since js-peer-id implements a IPFS PeerID, shouldn't this repo be js-ipfs-peer-id?
4. What steps would I take to create a PeerId that wrapped some other identity system (e.g. ssb-keys)

[daviddias]

Is there a spec for PeerId?

Not quite, this is more of a module I created as a convenient abstraction. go-ipfs has the Id generation code 'somewhere'

What is the mandatory API for a PeerId to expose?

From what I could extrapolate from its usage, the 'mandatory' API is what is implemented.

Since js-peer-id implements a IPFS PeerID, shouldn't this repo be js-ipfs-peer-id?

I left it as js-peer-id because it is also used by libp2p directly.

What steps would I take to create a PeerId that wrapped some other identity system (e.g. ssb-keys)

We would need multikey to be ready ipfs/specs#58

[hackergrrl]

Thanks for the quick response, as ever, @diasdavid!

Not quite, this is more of a module I created as a convenient abstraction. go-ipfs has the Id generation code 'somewhere'

PeerID is a core abstraction of libp2p, correct? This ought to be formalized and specced out at some point.

From what I could extrapolate from its usage, the 'mandatory' API is what is implemented.

Even the pretty printing utilities? What operations does a PeerID need to support? Just be a unique identifier (i.e. compare operation)? Be a pub/priv keypair? Use RSA? Ideally it would impose as few properties as possible and still be useful.

I left it as js-peer-id because it is also used by libp2p directly.

Right, but does it make sense that that libp2p shouldn't depend on an IPFS-specific piece like this? Shouldn't libp2p depend on the PeerID interface, not a concrete impl like this?

We would need multikey to be ready ipfs/specs#58

Identity != keypair though, right? Where possible we should prefer opaque identifiers.

[daviddias]

Shouldn't libp2p depend on the PeerID interface, not a concrete impl like this?

I see where your mind is headed, yes, do understand and agree. Although wouldn't say it it a priority right now, note that in the end of the day, and IPFS id is really just a identifier of how the note is recognised in the network, think about it as if it was a mobile IP.

Identity != keypair though, right? Where possible we should prefer opaque identifiers.

In IPFS case, right now, identity === keypair, not that each time you connect to a peer, you: a) get his PubKey b) validate that PubKey encodes to its peerId (b58.encode(multihash(pubkey, sha-256)) c) do an handshake with a challenge (like TLS) d) confirm that you are actually connected to the right peer.

[hackergrrl]

> Identity != keypair though, right? Where possible we should prefer opaque identifiers. In IPFS case, right now, `identity === keypair`, note that each time you connect to a peer, you: a) get his PubKey b) validate that PubKey encodes to its peerId (b58.encode(multihash(pubkey, sha-256)) c) do an handshake with a challenge (like TLS) d) confirm that you are actually connected to the right peer.

Yes, this is a great argument for making PeerID different from an "IPFS Identity" :+1. PeerIDs should be a means to identify a peer in the network, and all libp2p users may not employ a) SHA-256, b) multihashes, c) B58 encoding, and heck maybe even d) keypairs.