You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There seems to be no strict policy on such basic things as a generation of PeerId ( #6133 ) meaning that if I am attempting to generate peer id on my own (see below), there will be no guarantee that my code will not break with a next IPFS update.
// recovery of public key from ethereum transactionpkbin, err:=secp256k1.RecoverPubkey(msg, sig)
check(err)
// generation of a peerid from the recovered PKpk, err:=UnmarshalSecp256k1PublicKey(pkbin)
check(err)
pid, err:=peer.IDFromPublicKey(pk)
check(err)
fmt.Println(pid.Pretty())
So it would be great to put all that code on PeerId generation into the IPFS and provide an interface to obtain the PeerId from public key.
Please let me know if you agree so I will write the code.
The text was updated successfully, but these errors were encountered:
So, we're trying to work out the policy, that's why this is changing. I'm not sure adding an API to work around what's effectively a temporary bug is the best idea.
PULL REQUEST proposal
There seems to be no strict policy on such basic things as a generation of PeerId ( #6133 ) meaning that if I am attempting to generate peer id on my own (see below), there will be no guarantee that my code will not break with a next IPFS update.
So it would be great to put all that code on PeerId generation into the IPFS and provide an interface to obtain the PeerId from public key.
Please let me know if you agree so I will write the code.
The text was updated successfully, but these errors were encountered: