signed peer records: make them actually usable
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 6.9k
- Forks
- 1.3k
- Avg merge
- 13d 21h
- Merged PRs (30d)
- 1
Description
To be able to retrieve signed peer records, we need to store the serialized format, thanks to their non-deterministic serialization.
We also need to store the contents in the peer store, if we actually want to use the contents.
The current peer store API makes using signed peer records very cumbersome:
https://github.com/libp2p/go-libp2p/blob/5a0411b8eba4276b907c21fefc3adebde19096f1/core/peerstore/peerstore.go#L123-L181
Most importantly, it doesn't allow us to filter addresses, it's all or nothing. This is a problem for #2300, and will be for Kademlia, once it adds support for signed peer records (see https://github.com/libp2p/go-libp2p-kad-dht/pull/839).
In identify, we currently accept any signed peer record the peer sends us, without even checking that it's the peer's signed peer record (any correctly signed record will be accepted).
What we should do instead is the following:
1. Remove the `CertifiedAddrBook` interface.
2. Use the regular `AddAddrs` API to add save the addresses contained in the signed peer record.
3. Save the serialized bytes of the record in the metadata.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the peer store API in core/peerstore/peerstore.go, especially the CertifiedAddrBook interface and AddAddrs API, then trace how identify handles signed peer records. Review the metadata storage path and the signed peer record handling described in the issue. Done means the interface is removed, contained addresses are stored through AddAddrs, and the serialized record bytes are retained in metadata.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- networking
- Issue type
- Refactor
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100