feat: Store reliability

[weboko]

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.

[fryorcraken]

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

[weboko]

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.

[fryorcraken]

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.

waku-org/pm#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 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.

[weboko]

Moving to Blocked for now to clarify expected result of this work and it's benefits as was discussed during last Reliability meeting.

[fryorcraken]

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.

[jm-clius]

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.