Skip to content

Add active peer probing and reputation caching #53

@lidel

Description

@lidel

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 add transport-ipfs-gateway-http to Protocols 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

Metadata

Metadata

Assignees

No one assigned

    Labels

    P1High: Likely tackled by core team if no one steps updif/hardHaving worked on the specific codebase is importantkind/enhancementA net-new feature or improvement to an existing feature

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions