You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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;
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
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:
Filter scoring (with use of Store):
Light push scoring (with use of Filter):
Other strategies that might be used(each should be discussed):
Notes
Decoupled from discussions in #1463
The text was updated successfully, but these errors were encountered: