Hello Vac Team,
First of all, thank you for making Waku! I’m late to the p2p messaging party and was dismayed to find that Whisper is deprecated, and not even geth supports it anymore. But no matter, because Waku now exists and you all seem very serious about carrying the torch.
As the topic states, I have some questions about the js-waku API (for pure browser use). I got the basic functionality up and running with no trouble (thanks to the excellent readme examples on the github repo). However, the queryHistory is giving me some issues due to my lack of understanding - particularly around obtaining the right storePeerId.
In the chat example, it seems there is a direct libp2p callback being attached in order to obtain this value, however in my Waku experiment I’ve not been able to get such a callback to fire - though this is almost certainly related to my less-than-expert grasp of raw Javascript/React (I’m using F# via Fable, with some minimal JS interop).
So, my questions:
-
Is a queryHistory-capable peerId eventually going to be exposed in the Waku API proper? Anything special I need to know about getting change:protocols to fire on libp2p.peerStore ?
-
Are there any examples at present of the light push API?
-
Is deleting the content topic from relay.observers the correct way of removing a topic observer?
-
Will it be possible to either cancel the queryHistory callback at some arbitrary point (eg when a certain prior message age is reached), or otherwise set limits on it? Ideally I would only care about a fixed number of prior messages (eg 50 or less). And in my use case, the user is likely to click away from a given chat topic before it finishes loading old messages, so being able to fully cancel a query might be helpful.
-
Did I read correctly (somewhere, can’t remember where) that something like 1% of nodes would need to be full (non-browser) nodes, for everything to scale? My app will initially be desktop-centric despite running in a browser, so perhaps I can come up with some ways to incentivize running a full node (better chat experience etc). No promises, but if I’m using Waku, I’d want the app to be a good citizen.
I think that’s all for now! Let me know if I’m in the wrong place for asking this sort of thing.
2 Likes
Hello there!
Glad to see your excitement and thank you for the feedback.
First, do note that an issue was raised to make the peerId parameter optional for store query: queryHistory should make storePeerId an optional parameter · Issue #184 · status-im/js-waku · GitHub
Indeed, a developer may not care about which store they use to retrieve data, as long as the data is retrieved. Also thanks to 21/WAKU2-FAULT-TOLERANT-STORE | Vac RFC, it will not matter what node will be used (work in progress).
In the chat example you pointed out the hook operates as follows:
If a change:protocol event is emitted from libp2p.peerStore, then check the new protocols of the given peer. If it contains the store protocol id, then perform a store query.
change:protocol is typically emitted once the identify protocol is complete, which in turns is triggered when a new peer is connected.
This flows works well for a simple chat example: retrieve the history once connected to a peer store.
I hope it clarifies. Now, to your questions:
-
As mentioned earlier, the direction we opted for is that instead of exposing the peerId of an store node to then be passed to the queryHistory method, we just made it optional so you can let the library select the node for you.
However, if you still wish to select the peer manually, feel free to check selectRandomPeer to learn how you can check the protocol of the various peers your node is connected to.
-
Yes, eth-dm uses light push: js-waku/SendMessage.tsx at db6bb95a9b614bd29954dd4e73f14860c641f96e · status-im/js-waku · GitHub
-
I would recommend using the WakuRelay.deleteObserver API instead. See how it is used in Eth-DM to remove observer when a React component is unmounted: js-waku/InitWaku.tsx at db6bb95a9b614bd29954dd4e73f14860c641f96e · status-im/js-waku · GitHub
-
Very interesting! few notes:
a. There is upcoming support of start/end time parameters in the store query, tracked with Implement Waku v2 Fault-Tolerant Store · Issue #187 · status-im/js-waku · GitHub.
b. Would the start/end time be enough? Or would you still want to cap the response size (e.g. 50 msg max)? If the cap is needed, please open an issue so we can consider it: https://github.com/status-im/js-waku/issues/new
c. At the moment, there is no way to cancel the query, feel free to open an issue to request the feature: https://github.com/status-im/js-waku/issues/new
-
You must have read it here: Vac - What's the Plan for Waku v2?. Please note these are estimations. At the moment we are still designing and working on such ideas (pushing user to run full node locally) for Status products. I think we can give a more concrete answers when things are more mature and advanced.
Thanks again for the questions and feedback. Looking forward to learn more about your project!
Edit: Answer question 5.
Thanks so much, @fryorcraken! For responding in such excellent (and immediately useful) detail!
That’s great about the optional peerId arguments (and deleteObserver) - sounds like I’m just 1 release away from everything exactly the way I would use it.
And I did finally get the change:protocols event working - turns out I was installing the handler too late, before observing on a topic, instead of before connecting to peers - all sorted now, thanks to your assistance. Likewise I’m now using the light push as well, saving the peerId during the same protocols callback.
re: queryHistory limits - start/end time will be sufficient for now, and I’ll open a “max limit” issue later down the line so as not to distract you all from other more urgent development - same with cancelation.
Yes, I’ll be happy to share my big project when it finally goes live. In the meantime, here is my Waku testbench + the hosted version:
Workbench repo
Hosted
Thanks again!
1 Like