js-waku
js-waku copied to clipboard
waku-org
feat: Store reliability
This is a feature request
Problem
Overall Store protocol is not reliable in Waku network as it is up to a service node what retention time to use etc.
Specifically to js-waku protocol is using only one peer to query store.
Proposed Solutions
To improve reliability we should research and if possible to implement ability to query multiple nodes at the same time. This might involve a need to merge requested messages to remove duplicates etc.
This option can be added as optional parameter before we understand if it is a good default behavior.
IMO, store reliability will be a side effect of https://github.com/waku-org/pm/issues/64 which makes it light and easy to use multiple store nodes to ensure no messages are missed, without overwhelming both store nodes and client bandwidth.
I'd suggest to close this issue for now as the work described seemed to be in the scope of https://github.com/waku-org/pm/issues/64
To me it seems as these issues are coming together. When #64 is done we have a way to find Store nodes but it is not guaranteed that their overall reliability will be OK.
Maybe it will make more sense if we make proposed solution in this issue less specific and more centered around finding a way to find a reliable node for Store queries.
When #64 is done we have a way to find Store nodes but it is not guaranteed that their overall reliability will be OK.
Indeed #64 's scope seem quite restrictive.
https://github.com/waku-org/pm/issues/57 provides more details on the output and
store sync mechanism based on message IDs
Is what I had in mind regarding store reliability
Fine to keep this issue, action item would be to set an owner for https://github.com/waku-org/pm/issues/64 on js-waku side to ensure we track the work and keep in mind that we want to improve resilience in general cc @waku-org/js-waku-developers.
nitpick: I don't think we can make store server more reliable at this point in time (at least until we have an idea on what incentivization looks like and whether it addresses reliability dimension). I think this issue is focused on store API reliability or resilience to store server un reliability.
Moving to Blocked for now to clarify expected result of this work and it's benefits as was discussed during last Reliability meeting.
Moving to Blocked for now to clarify expected result of this work and it's benefits as was discussed during last Reliability meeting.
Aligned with that, for now the assumption is that store nodes have all messages, thanks to store sync.
I would also add that doing multiple store queries may not be the right approach to finding missed messages once e2e reliability is in place, but instead, ask the participant to resend.
Cc @jm-clius to confirm but I'd suggest to close this because not in line with the direction we want to take.
Yes, we can close. In future, I think it could worthwhile specifying the implied trust and reliability assumptions in Store protocol. Even if we do not implement any strategies, rigorous description of how redundancy, query consolidation, etc. affects the protocol when seen in isolation (i.e. apart from sync strategies). For now, however, this is out of scope, so happy to close.
Closing as we discarded idea of having redundancy for Store.
Store v3 should be reliable enough - https://github.com/waku-org/js-waku/issues/2029 Another improvement can be done for Filter - https://github.com/waku-org/js-waku/issues/2008