Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Signed peer records for IPFS DHT #26

Open
Tracked by #54
guillaumemichel opened this issue Jun 27, 2023 · 0 comments
Open
Tracked by #54

Signed peer records for IPFS DHT #26

guillaumemichel opened this issue Jun 27, 2023 · 0 comments
Labels
scope/nicetohave Nice to have feature going beyond go-libp2p-kad-dht

Comments

@guillaumemichel
Copy link
Contributor

guillaumemichel commented Jun 27, 2023

The IPFS DHT has the capability to use Signed peer records. We should definitely use them as they add security.

This should be implemented in the ipfsv1 message format, an optional signature field can be added in the protobuf Peer message https://github.com/plprobelab/go-kademlia/blob/dc867cbd3316a89cabaa5be19900cdbf5d2f0805/network/message/ipfsv1/message.proto#L60-L69

An IPFS server should provide the signature associated with the closest peers (peer records) it returns if any. IIUC the signatures are stored in the libp2p host peerstore, hence in addition to the ipfsv1 message module, the libp2p endpoint module also has the be updated.

We also need to make sure that the IPFS node shares its own signed peer record, otherwise the signed peer records cannot propagate. I am not sure if this is done in libp2p or if we should actively add a peer's signed record to DHT messages.

References

@guillaumemichel guillaumemichel added the scope/nicetohave Nice to have feature going beyond go-libp2p-kad-dht label Jun 27, 2023
@iand iand moved this to Unplanned in DHT Optimization Jul 11, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
scope/nicetohave Nice to have feature going beyond go-libp2p-kad-dht
Projects
Status: Unplanned
Development

No branches or pull requests

1 participant