The learnings led to more justification and precision in terms of reducing the store API in Waku API: No store in Messaging API
We know have a clear consumer for the Waku API: reliable channels.
Which means that store related functions on the Waku API need to be sufficient for reliable channel, aka SDS, and nothing more.
So it means exposing store hash queries, to find messages based on retrieval hints. This is fine and expected, and hash queries should be fine re optimization.
However, it does not mean exposing time range queries, but assuming that they are being triggered and used as per P2P-RELIABILITY specs.
One optimization I have demonstrated in js-waku reliable channels is that when time range queries are done, they are done backward in time, and can be stopped based on a hook.
In the case of SDS, it means finding a message with valid causal history. So that from then, hash queries can be used to retrieve the other messages.
This is something we actually may want to force upon developers, having to pass such hook, to make them think of a way to optimize message retrieval.
Do note that the main difference between js-waku’s reliable channel implementation and the store reliability in P2P reliability specs is that instead of doing periodic time range queries (spec), it (js):
- periodic hash queries based on missed messages as identified by SDS
- backward time range range query from now until last successful store query upon connecting to a new store node
To be reviewed regarding aligning JS and the Spec.