Open ghost opened 7 years ago
This isn't that easy as our key isn't valid CIDv0 object. We could go with CIDv1 and multikey if we had multikey.
@lgierth As I understand you were thinking "Hey, the whole IPFS is about getting back from hash to a content that was hashed. Peer IDs and ipfs key
IDs are just a hash of their public key. Why not resolve those IDs to the content that was hashed?"
And you are right. But the /ipfs namespace is hashing content differently than how the /pk namespace does. This /pk namespace is used internally by /ipns to check signatures of the records. If you are able to resolve /pk/QmBlah in the DHT today, and you would ipfs add
that content (the binary representation of the public key), you would end up with something that is not /ipfs/QmBlah, but some /ipfs/QmSomethingElse
So do you envision storing public keys in both formats for a transitional period and then getting rid of the /pk namespace?
@wigy-opensource-developer We could still store the public keys in ipfs, if you extract the public key and add it as a block with sha256 hashing, it should all work out.
cat public.key | ipfs block put
Version information: 0.4.9-dev
Type: enhancement
Severity: Low
Description:
A node should maybe ipfs-add its own public key during init, so that fetching /ipfs/Qmfoo works, where Qmfoo is the node's peerid.
And maybe the same for keys from
ipfs key
.