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
Instead, the key could be directly lookup up using the content lookup interface of the DHT. This interface takes a CID and respond with a list of peers directly. This is exactly what we need.
I suggest that we add an encoding in the CID to represent a public key from the key hash to avoid the two phase lookup. This is what this ticket is for.
I also suggest that instead of taking a pointer to a CID value, the routing interface references an interface type instead, that could be implemented differently. This is to be tracked in libp2p/go-libp2p-routing.
Don't hesitate to chat with me over IRC, realtime makes it easier to remove ambiguities
The text was updated successfully, but these errors were encountered:
mildred
changed the title
Allow CID to reference anything (extensible)
Allow CID to reference public keys (possibly make it extensible)
Dec 27, 2016
@mildred agreed on wanting a CID codec to easily reference keys. We want to use ipld to do this, and call the format multikey.
However, we could address the problem you bring up without that. If peers added their public keys into the blockstore then you could move them around with bitswap, and peers could fetch public keys that way instead of requiring a dht query
FYSA we now have libp2p-key multicodec, it is used for representing PeerIDs as CIDs: multiformats/multicodec#130
This issue is pretty old, so I am closing this.
A lot changed since then, revisited DHT improvements can be proposed in upstream go-ipfs or libp2p repos.
See message on IRC: https://botbot.me/freenode/ipfs/msg/78509267/
Currently, when looking up public keys, the generic value store interface of the DHT is used.
This has the effect that when, for example looking up a public key (but this is the same for naming), the DHT is queried twice. Once for the correspondance between the public key fingerprint to know the block id and once more to get the list of peers that can provide the block with the id we just got.
Instead, the key could be directly lookup up using the content lookup interface of the DHT. This interface takes a CID and respond with a list of peers directly. This is exactly what we need.
I suggest that we add an encoding in the CID to represent a public key from the key hash to avoid the two phase lookup. This is what this ticket is for.
I also suggest that instead of taking a pointer to a CID value, the routing interface references an interface type instead, that could be implemented differently. This is to be tracked in libp2p/go-libp2p-routing.
Don't hesitate to chat with me over IRC, realtime makes it easier to remove ambiguities
The text was updated successfully, but these errors were encountered: