js-peer-id
js-peer-id copied to clipboard
Does a peer id require the private key and the public key to be carried around?
In this implementation of peer, it appears the constructor allows undefined public key and private key, is this meant to be allowed, or is peer id only useful if both pub and priv keys are available?
The go implementation appears to indicate that these keys are optional, and that if you want to access further functionality, you should pass them into the relevant functions.
@CMCDragonkai The Public Key is derived from the Private Key. ~~These keys are not optional.~~ Only the private key is optional
If they are not optional, how come the constructor of a peer doesn't enforce that both keys must be present for a correctly constructed peer object. https://github.com/libp2p/js-peer-id/blob/master/src/index.js#L13-L24
PeerId is used as a general abstraction within libp2p and IPFS code, i.e. your peer id string representation that gets wrapped in the PeerId object for internal consumption - the keys are optional for that use case. In other words, internally libp2p and ipfs uses PeerId everywhere to represent a peer, even tho the keys might not be absent.
Fixed my statement. Only the PrivateKey is optional.
If only the private key is optional, then why is this allowed? https://github.com/libp2p/js-peer-id/blob/master/src/index.js#L151-L161 Creating a peer id from a buffer doesn't automatically derive the public key.
I think it's allowed because sometimes when dialing a peer whose peer id is known (as it's encoded in the address) but the pubkey is not known it is useful to create a peer id object only to validate whether the ids match (like it is done in secio here)
@CMCDragonkai is it possible to get public key from B58 string?
@Jonybang Generally it's not possible to get the public key from just the id, since the id is a hashed version of the publickey. Instead you can only verify whether a publicKey belongs to a peerid by hashing that public key.