vpavlin
commented
8 months ago I think the user stories sound good and pretty comprehensive.
My main issues stemmed from a few things so far
-
Unreliable Filter - seemed like the filter nodes just stopped propagating messages to my app (even with ping on), so I had to resubscribe - but js-waku kept trying to resubscribe to the same node, which for some reason would not work. So having multiple filter nodes and js-waku (or the library) keeping track of this would save a lot of trouble
-
Unrelaiable Lightpush - after a while I started getting "Remove peer fault" errors and the only thing I could do was to retry. It would be great if the library could just pick different LIghtpush node in case sending fails multiple times
-
As my filter subscription was failing, I always missed a few messages, so I kept track of the last received message and tried to query store for anything from that timestamp till now.
I implemented all of these in https://github.com/vpavlin/waku-dispatcher/blob/main/src/dispatcher.ts, so it would be great if we can have them in an official library
weboko
fryorcraken
chaitanyaprem
chair28980
Milestone: https://github.com/waku-org/pm/milestone/7
NOTE: the work originally defined in this issue has been split between the following deliverables:
Epics
NOTE: Epics updated to fit within the above 2 Deliverables.
Summary
Deliverables:
Provide recommendation in a form of a library to compose the Waku protocols to minimize message loss at a protocol level. This is both for relay and non-relay node. The aim is to provide opinionated libraries that use Waku in a generalized manner. The library may not fit all use-case and can always be bypassed or forked.
Finally, the expectation is not 100% reliability but simply increased reliability for common scenarios. Application level solution for more certitude are covered as part of Minimum Viable Data Synchronization.
This is part of the general SDK strategy and expected to be implemented in each language:
Note that these SDKs needs to be reliable enough so that any developer can build a PoC application and reach a fair level of reliability. However, it is assumed that when a developer want to push an application to MVP level or further, deeper understanding of Waku is needed to fine tune Waku usage to the application.
Functionalities/User Stories
First attempt to define a functional scope for this milestone:
A. relay node
B. non-relay node
Implementation Notes
Relay client
Non-relay client
Receiving messages:
Sending messages:
js-waku vs NodeJS bindings.
API for this output for js-waku and NodeJS bindings should aim to be aligned as much as possible, even if js-waku is non-relay and NodeJS is relay node.
Dependencies
To deliver the reliability part, this would depends on store v3 protocol to get access of message hashes. On research side, couple of weeks left on this (as of 19 Feb) and iteration on nwaku needed.