github-actions[bot]
commented
2 days ago size-limit report 📦
| Path | Size | Loading time (3g) | Running time (snapdragon) | Total time |
|---|---|---|---|---|
| Waku node | 183.32 KB (+0.09% 🔺) | 3.7 s (+0.09% 🔺) | 5.5 s (-14.61% 🔽) | 9.2 s |
| Waku Simple Light Node | 183.42 KB (+0.14% 🔺) | 3.7 s (+0.14% 🔺) | 4.2 s (-22.88% 🔽) | 7.9 s |
| ECIES encryption | 23.12 KB (0%) | 463 ms (0%) | 1.3 s (+16.63% 🔺) | 1.7 s |
| Symmetric encryption | 22.58 KB (0%) | 452 ms (0%) | 1.9 s (+31.27% 🔺) | 2.4 s |
| DNS discovery | 72.49 KB (0%) | 1.5 s (0%) | 3.9 s (+6.93% 🔺) | 5.4 s |
| Peer Exchange discovery | 74.15 KB (0%) | 1.5 s (0%) | 3.8 s (+19.85% 🔺) | 5.3 s |
| Local Peer Cache Discovery | 67.68 KB (0%) | 1.4 s (0%) | 2.7 s (-49.97% 🔽) | 4 s |
| Privacy preserving protocols | 38.87 KB (0%) | 778 ms (0%) | 2.4 s (+89.18% 🔺) | 3.2 s |
| Waku Filter | 112.88 KB (+0.21% 🔺) | 2.3 s (+0.21% 🔺) | 3.3 s (-8.88% 🔽) | 5.5 s |
| Waku LightPush | 111.2 KB (+0.09% 🔺) | 2.3 s (+0.09% 🔺) | 4.2 s (-4% 🔽) | 6.4 s |
| History retrieval protocols | 111.61 KB (-0.05% 🔽) | 2.3 s (-0.05% 🔽) | 3.5 s (-16.4% 🔽) | 5.8 s |
| Deterministic Message Hashing | 7.29 KB (0%) | 146 ms (0%) | 647 ms (+80.55% 🔺) | 793 ms |
Problem
When using the Filter protocol, we create subscriptions with multiple peers. This increases the inherent reliability considering we have multiple nodes that can provide us with an incoming Filter messages. To continue this effort, it is helpful to be able to observe the nodes that are not as reliable specifically, and act on renewing them with potentially healthy peers.
Solution
As part of increasing reliability for Filter, doing recurring Filter pings on nodes with whom we have open subscriptions and expect incoming Filter messages from:
Notes
Contribution checklist:
!in title if breaks public API;