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

Add active peer probing and reputation caching #53

Open
lidel opened this issue Mar 14, 2024 · 1 comment
Open

Add active peer probing and reputation caching #53

lidel opened this issue Mar 14, 2024 · 1 comment
Labels
dif/hard Having worked on the specific codebase is important kind/enhancement A net-new feature or improvement to an existing feature P1 High: Likely tackled by core team if no one steps up

Comments

@lidel
Copy link
Member

lidel commented Mar 14, 2024

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/http, /https, /webrtc*, /webtransport)
  • 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
@hacdias hacdias removed their assignment May 27, 2024
@aschmahmann aschmahmann added kind/enhancement A net-new feature or improvement to an existing feature dif/hard Having worked on the specific codebase is important P1 High: Likely tackled by core team if no one steps up labels Jun 18, 2024
@2color
Copy link
Member

2color commented Sep 11, 2024

Adding some notes from a call with @lidel:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
dif/hard Having worked on the specific codebase is important kind/enhancement A net-new feature or improvement to an existing feature P1 High: Likely tackled by core team if no one steps up
Projects
None yet
Development

No branches or pull requests

4 participants