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

feat: peer scoring strategies for light protocols #2017

Open
weboko opened this issue May 14, 2024 · 2 comments
Open

feat: peer scoring strategies for light protocols #2017

weboko opened this issue May 14, 2024 · 2 comments
Labels
enhancement New feature or request

Comments

@weboko
Copy link
Collaborator

weboko commented May 14, 2024

This is a feature request

Problem

Peer scoring for light protocols should improve overall quality of peers being used by a node. This should drive satisfaction from the service provided as well as perceived reliability.

Proposed Solutions

Filter scoring:

  • Subscribe to 2 peers and compare if 1st broadcasts messages faster than 2nd;

Filter scoring (with use of Store):

  • Check if any of present subscriptions misses any messages by using store pings;

Light push scoring (with use of Filter):

  • Check if a message sent through peer A was relayed from any of the Filter subscriptions;

Other strategies that might be used(each should be discussed):

  • Pretense of Relay protocol is beneficial for other protocols;
  • If we know IP we can try to decide if a peer is close to us geographically (note that these should not be the only peers a node is using but some);
  • Investigate if libp2p ping can be used to measure latency;
  • Blacklist peers that drop connection with us more than once;
  • Monitor errors during Filter ping / Filter subscribe / Lightpush send and other operations within protocols - decrease score for such peers;

Notes

Decoupled from discussions in #1463

@danisharora099
Copy link
Collaborator

Peer scoring for light protocols should improve overall quality of peers being used by a node.

scoring was decided to not be introduced for the scope of js-waku currently (ref: #1463 (comment), #1463 (comment)) as js-waku is a relatively short-lived connection when compared to its full-node counterparts where scoring offers a much more substantial advantage.

If we know IP we can try to decide if a peer is close to us geographically (note that these should not be the only peers a node is using but some);
Investigate if libp2p ping can be used to measure latency;

We do this part of finding connections to peer currently: peers with lowest latency are given priority

@weboko
Copy link
Collaborator Author

weboko commented Jun 20, 2024

Agree that we have no deliverable in this issue.
I think we should revisit it sometime in the future.

Iceboxing for now

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
Status: Icebox
Development

No branches or pull requests

2 participants