-
Notifications
You must be signed in to change notification settings - Fork 42
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: Store reliability #1685
Comments
IMO, store reliability will be a side effect of waku-org/pm#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 waku-org/pm#64 |
To me it seems as these issues are coming together. 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. |
Indeed #64 's scope seem quite restrictive. waku-org/pm#57 provides more details on the output and
Is what I had in mind regarding store reliability Fine to keep this issue, action item would be to set an owner for waku-org/pm#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. |
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. |
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.
The text was updated successfully, but these errors were encountered: