-
Notifications
You must be signed in to change notification settings - Fork 6
Closed
Labels
P1High: Likely tackled by core team if no one steps upHigh: Likely tackled by core team if no one steps updif/hardHaving worked on the specific codebase is importantHaving worked on the specific codebase is importantkind/enhancementA net-new feature or improvement to an existing featureA net-new feature or improvement to an existing feature
Description
Someguy should be able to cache (#25) peerbook info returned on /routing/v1/providers
, and build reputation over time for returned PeerIDs.
Goals
- P1: active probing of discovered peers
- run libp2p identify in the background, cache results in peerbook for more than 48, e.g. 72h, remove need for client to probe PeerIDs to learn multiaddrs and supported protocols
- P1: return more stable / online PeerIDs first, and ones that have multiaddrs cached most recently
- P1: prioritize peers useful in browser context (
/wss
,/tls/../ws|http
,/https
,/webrtc*
,/webtransport
) - P1: confirm when
/tls/../http
and/https
is a trustless gateway, and addtransport-ipfs-gateway-http
toProtocols
list in respective peer - P2: build "badlist" and skip peers with well-known-deprecated transports, for example:
ipfs id --peerid-base base36 QmbNSJi9X4Phf5G6YgmVYWZiCzraLp5Ta4GT2XYHPwzE5S
produces
[/ip4/3.75.101.246/udp/4001/quic] QUIC draft-29 has been removed, QUIC (RFC 9000) is accessible with /quic-v1
and[/ip4/3.75.101.246/tcp/4001] failed to negotiate security protocol: read tcp4 192.168.50.102:4001
Implementation ideas
I imagine we could start with something built on top of peerbook system where every PeerID has additional attributes:
last time PeerID was returned
with/routing/v1/
response- allows us to do cache eviction of no longer relevant PeerIDs
how many times PeerID was returned
with/routing/v1/
response- allows us to identify peers more important than others, because their presence impacts more users
last time PeerID was probed
/last time PeerID was seen online
- allows us to prioritize peers which are online and useful due to their transport and protocols
Active probing could be async, going over peers with last time PeerID was seen online
older than N (6?) hours and trying to connect to them and
- run identify, if libp2p multiaddr is present
- run trustless gateway probe, if potential HTTP endpoint is present
2color
Metadata
Metadata
Assignees
Labels
P1High: Likely tackled by core team if no one steps upHigh: Likely tackled by core team if no one steps updif/hardHaving worked on the specific codebase is importantHaving worked on the specific codebase is importantkind/enhancementA net-new feature or improvement to an existing featureA net-new feature or improvement to an existing feature