Trim address sets (in the peerstore itself) with more than 10 addresses per transport
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 6.9k
- Forks
- 1.3k
- Avg merge
- 13d 21h
- Merged PRs (30d)
- 1
Description
Most users should advertise 3-4 addresses:
- localhost (only on localhost conns)
- interface addr
- public ipv6
- public ipv6
We should filter peer addresses in the peerstore if a peer advertises more than 10 addresses for a single transport:
- Prefer public addresses.
- Prefer the address/port we observe on the connection. This may be hard to do in the peerstore? I'm not sure if this is filter is really necessary.
- Prefer addresses that share the same port across an IPv4 and IPv6 variant. That is, if I have /ip4/1.2.3.4/tcp/1234 and /ip6/2000::5/tcp/1234, I should keep those over addresses where I only have an IPv4 or IPv6 address for the port. A shared port is an indication that the address is actually valid.
Really, if the peer advertises more than 10 addresses per transport, I'm fine just dropping a bunch of them.
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 peerstore's address handling and transport-specific address sets, then trace how connection-observed addresses are recorded. The issue needs a decided policy and tests showing that sets over 10 are trimmed while public, observed, and shared-port addresses are preferred; otherwise, excess addresses may simply be dropped.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- networking
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100