Closed fryorcraken closed 6 months ago
Regarding this. Is c-binding the best solution? Should we just start with providing a go-waku npm packages for NodeJS, similar to the React Native one?
Cc @richard-ramos
@Ivansete-status I have adapted this issue to track nwaku c-bindings work in general. Note that hte NodeJS Wrapper is the most important deliverable but as you did the work for Python and golang as part of this, I included it in the milestone.
Weekly Update
libwaku
with the working-thread approach. The example had been receiving relay messages during a weekend. The memory was stable without crashing. Weekly Update
Weekly Update
Weekly Update
Weekly Update
Weekly Update
achieved:
libwaku
.next: Separate the PR mentioned above and submit another one which only avoids using global variables but doesn't add the wip-Rust integration.
Weekly Update
achieved:
next: Start creating a separate NodeJs and Python repositories, where we will create nodejs-waku and py-waku, respectively.
@fryorcraken, @chair28980 - This can be considered as completed because:
The NodeJs repo has been created, and from there nodejs-waku
packages can be built: https://github.com/waku-org/waku-nodejs-bindings
The Python repo has been created, and from there py-waku
packages can be built: https://github.com/waku-org/waku-python-bindings
Besides, I've moved the following tasks to the upcoming epics:
@fryorcraken - I'm closing this because we have NodeJs
and Python
repos available as stated in my previous comment.
@chair28980:
I've added the following points to the https://github.com/waku-org/pm/issues/141 issue, and I removed the point that referred to this issue that I'm closing (nwaku/issues/1332)
Planned start date: started ~May'23 Due date:
Summary
nwaku is the reference implementation of the Waku protocol. To enable developers to use the reference implementation in their native application, nwaku needs to expose c-bindings. As Nim is a garbage collected language, integration in other garbage collected languages such as NodeJS or Python may not be straightforward, as one needs to ensure that the garbage collector of either languages to not conflict with each other
Acceptance Criteria
Tasks
[ ] Adapt https://rfc.vac.dev/spec/36/ as per changes in proc signatures.[ ] Extend the waku implementation protocols. So far only therelay
protocol is supported. Before that, we need to have a solidrelay
implementationnwaku
as a submodule.nwaku
as a submodule.Future Tasks
relay
protocol is supported. Before that, we need to have a solidrelay
implementationRAID (Risks, Assumptions, Issues and Dependencies)
Original issue
### Problem NodeJS is used by projects such as RAILGUN to build a backend/node. Currently, developers of such projects have the following choices: - integrate js-waku: not ideal as js-waku targets the browser environment and hence is lacking service node feature such as: - server side implementation/performance optimization of protocols (e.g. store, filter, light push) - RLN (currently only exporting zerokit to wasm for the browser, which does not work in NodeJS due to difference in APIs) - Use nwaku or go-waku as a service node - via JSON RPC API (which is limited) - via HTTP REST API (not yet delivered) - Use go-waku c-bindings (which requires work to do as we do not provide a JS wrapper at this stage None of the choices above are ideal/straightforward. ### Acceptance Criteria A clear strategy to integrate nwaku in NodeJS. Two steps will be required: 1. Select the most efficient way for NodeJS and Waku to communicate (REST API? Unix socket? C-binding? etc) 2. Deliver an off-the-shelf solution/wrapper so that a user can install a npm package and communicate with their nwaku node 3. Deliver an off-the-shelf solution/wrapper so that a user can install a npm package and deploy/run a nwaku node (3) can be done at a later stage/tracked with a new issue once (1) and (2) are done.