[BOUNTY] Develop a front-end for waku nodes

alrevuelta commented 1 year ago

Context

Waku Is Uncompromising Web3 Communication at Scale. A family of robust, censorship-resistant communication protocols, designed to enable privacy-focused messaging for web3 apps.

An nwaku node can be used to publish/subscribe messages into the network, but there is currently no UI available to easily do so for non-techie users.

Currently, users must:

Using the rest/json api via curl or other method, dealing with the terminal and commands that are not very user friendly. The user has to also deal with encoding/decoding, manually inputing timestamps, all this without any user interface.
Connecting to the node using a light protocol, via one of the js examples. However one must ensure that the ports are open, manually copy/pasting the address and ensuring its properly integrated before being able to publish the message.

Both solutions are too technical for an average user that just landed on waku and wants to interact with the protocol by using some of the features it provides.

Disclaimer: Waku is experimental, you may find blocking issues while developing your web app. We will prioritize their resolution to unblock you, which means you may have to pause development until done. Thank you for your patience and understanding.

Your participation in this bounty is subject to your acceptance of our terms and conditions. Please see https://github.com/waku-org/bounties#applying-for-a-bounty for details.

Rewards

1000 DAI

Timeframe to Completion

Once the application is approved, the result must be submitted within 30 days.

Application Evaluation

To ensure you are selected for this bounty, provide the following information:

Describe the approach you will take to tackle the bounty.
A timeline within which you expect to deliver the bounty.
Any previous relevant work you have done.

Skill Requirements:

Some knowledge in front end technologies
Ideally some UI design experience
Ideally some prior waku knowledge
Containers experience

Bounty

This bounty proposes the development of a front end that allows the user to interact with a local waku node using the RPC endpoints, providing the following functionalities:

1) Publish a message to a given topic(s) 2) Subscribe to a given topic(s) 3) Fetch messages via store protocol and show them in a box (eg last x days)

The idea is to integrate this frontend with nwaku-compose so that when a user spins up everything, a simple front end will be available in the same machine at localhost:port and any non tech savvy user will be able to interact with its node, exploring some of the basic features that it offers. At some point we can also turn this feature into a node management interface, but out of scope by now.

As an example, other blockchain nodes offer a built in user interface that can be used to interact with the node. In these cases it's integrated natively in the node, but in our case by now we can have it separate. some examples:

prysm node, offers a UI to load validator keys, monitoring the attached validators, etc: https://www.youtube.com/watch?v=kRdEwOCMCdw
diva node, offer a UI that allows to integract with the node: https://www.youtube.com/watch?v=efkyU2oEygo leaving to the api, but procide some basic functionality.

Impact

Provide non technical users a way to interact with their waku node in a simple way, being able to use it as a chat with no prior knowledge. No need to set things up like now with js-examples and waku.
Useful for workshops as we currently relied on the RPC which is complex even for technical people.
~~Since RLN requires registering, this should reduce the friction by allowing to register in an easy way~~

Deliverables

D1. Dockerized frontend with a nice design and some waku branding. Avoid using fancy frameworks that soon become obsolete. With the following features:

Integrated with nwaku-compose so that after "docker-compose up -d" the front end is available to the user.
The front end allows to publish a message to a given content topic, inputting a set of fields. Using the RPC. Can take UTF-8 string or binary payload in hex format (using post_waku_v2_relay_v1_message)
The front end allows to subscribe to a given content topic, and messages are displayed real-time in there.

Acceptance Criteria

a Frontend that fullfils D1 requirements above
a PR opened on https://github.com/waku-org/nwaku-compose to add spinning up this front end as part of nwaku-compose, and instructions

Resources

Learn more about Waku at https://docs.waku.org/. Join our Discord to get support at https://discord.waku.org/.

Spec that describes JSON RPC API: https://rfc.vac.dev/spec/16/ Open API spec for REST API: https://github.com/waku-org/nwaku/blob/master/waku/node/rest/relay/openapi.yaml

fryorcraken commented 1 year ago

@NagyZoltanPeter do we have any doc re REST API that one can use to build this bounty?

NagyZoltanPeter commented 1 year ago

@NagyZoltanPeter do we have any doc re REST API that one can use to build this bounty?

Yes, we do have Rest API for relaying messages and subscribe to / unsubscribe from pubsubTopics. waku/v2/node/rest/relay/openapi.yaml describes it.

fryorcraken commented 1 year ago

@alrevuelta Can we please list the API expected to be used by the hacker because I do not see any REST API for the RLN membership one. If new API is needed, we can check with @NagyZoltanPeter and get it prioritized.

alrevuelta commented 1 year ago

Can we please list the API expected to be used by the hacker because I do not see any REST API for the RLN membership one.

@fryorcraken My bad. The rln membership registration doesn't really require to interact with the api. Its done directly with the contract. The UI just should allow to do this in an easy way. "Register a RLN membership by interacting with the contract and signing the tx via a simple interface"

Some extra info. We have the rfc for the different endpoints that are available. Main endpoints that willl need to be used:

post_waku_v2_relay_v1_message
get_waku_v2_store_v1_messages

vpavlin commented 1 year ago

Make sense, it should be reasonably easy to use JSON RPC now and switch to REST API later as long as good architecture patterns are chosen (i.e. good abstraction of actual calls to the node and decoupling from UI itself).

@alrevuelta I would avoid using the word "simple" in describing the features and requirements - it is vague and may mean different things to different people - hopefully the goal of the participant is always to make things simple, but most importantly with good user experience.

A few additional questions:

You talk about users needing to setup ports and public IPs, but if I don't do that, will my node receive any messages? If I subscribe to a content-topic on a node that is not publicly available, will I actually get the messages I expect?
The RLN registration - would it be better served by a separate dapp where you select / insert a membership contract and then execute the registration? Or is there a particular reason why it makes most sense to be part of the UI for the local node?
For REST API there are a bunch of options to have a UI to interact with it - from OpenAPI to things like Redocly (which Codex is using), so it may make more sense to spend time on promoting these than building an over-simplified version to only push and receive a message if we could have a full set of APIs covered available?

alrevuelta commented 1 year ago

You talk about users needing to setup ports and public IPs, but if I don't do that, will my node receive any messages? If I subscribe to a content-topic on a node that is not publicly available, will I actually get the messages I expect?

If by "node that is not publicly available" you mean behind a nat, yeap you will be getting the messages. As long as you can start the connection and have outgoing peers, thats fine. But its recommended to have also inbound peers. Unsure if related to this?

The RLN registration - would it be better served by a separate dapp where you select / insert a membership contract and then execute the registration? Or is there a particular reason why it makes most sense to be part of the UI for the local node?

Two reasons. i) is privacy, if we (waku or status) host this app then everyone registering will leak their ip with their index to us. ii) is that we dont have to run that infra, less stuff to maintain. Also, if we ship this with waku then the process of registering the membership and configuring waku with it can be done in one go via the UI. Out of scope by now, but aiming to reduce friction in RLN registration. Note that we cant refer as "dapp" here. The dapp is the contract, but if someone interacts with that "dapp" via us, well, its still a dapp in some sense, but privacy is lost.

so it may make more sense to spend time on promoting these than building an over-simplified version to only push and receive a message if we could have a full set of APIs covered available?

Yup, guess it is like postman. But note that this feature focuses on non tech savy users. The goal is not to support every api endpoint, but offer a very simple and curated UI thats abstract complexity even further. I indeed thin its better to build a "over-simplified version". Example, im sure redocly won't be integrated nicely with subscribing to msg (simple textbox that keeps printing the latest messages)

vpavlin commented 1 year ago

if we (waku or status) host this app then everyone registering will leak their ip with their index to us

How? Maybe I am missing the point, but this could be a single page app hosted on IPFS or something if you wanted to go all way.

Nothing prevents us baking a tracker into the image for the localy running UI which would send us the same info, but we would not want that, same for the hosted app.

Hmm, but would the RLN config survive a node restart then? If the keystore and whatever else is needed is not configured in env vars or CLI options and I spin my compose down and up - would I still have waku configured to work properly with my registration? (Assuming by "registering the membership and configuring waku with it can be done in one go via the UI" you mean using the REST or RPC to configure it)

The dapp is the contract, but if someone interacts with that "dapp" via us, well, its still a dapp in some sense, but privacy is lost.

My understanding what dapp represents is different - dapp to me is backend (contract + whatever other backend infra is necessary) and frontend (which can be in optimal case hosted by anyone) - so here it goes well with your proposal, but also is not necessarily the only way.

All fine, just wanted to provide differnet point of view, it is definitely cool bounty!

alrevuelta commented 1 year ago

How? Maybe I am missing the point, but this could be a single page app hosted on IPFS or something if you wanted to go all way.

well ofc i was thinking about a "normal" website. with ipfs it could work, but ux is quite bad, requires some extra development, resources. the approach suggested here is more simple, requires less resources and complies with the requirement (privacy). and well, even this doesnt 100% solve the issue if people use public ethereum endpoints, but at least thats not in our side.

Nothing prevents us baking a tracker into the image for the localy running UI which would send us the same info, but we would not want that, same for the hosted app.

yeah, but since everything is open source, people will know it.

you mean using the REST or RPC to configure it

yes. note that we dont have an endpoint for this by now. the idea is to be persisted but im fine initially with just being able to register the membership. im fine with leaving this "automatically membership configuration" out of scope by now and just enabling the registration, since its a bit losely defined.

fryorcraken commented 1 year ago

I updated the description to match template. Couple remaining questions/suggestions:

I propose to scope this bounty to send message/subscribe/retrieve from relay+store only. We can scope the RLN registration in a subsequent bounty
You mentioned "subscribe" and get_waku_v2_store_v1_messages this seems incorrect. Please confirm we expect:

a) send message over relay with post_waku_v2_relay_v1_message b) subscribe to live incoming message over relay with regular call on get_waku_v2_relay_v1_messages c) do a store query to a remote peer using get_waku_v2_store_v1_messages
Let's prefer REST API over JSON RPC but I agree it's not blocking. @NagyZoltanPeter are the 3 methods listed available on REST API?
I suggest a 1000DAI bounty with the relay send/subscribe+store scope.

@alrevuelta let me know your thoughts.

fryorcraken commented 1 year ago

another addition: UI to display some basic node info such as:

get_waku_v2_debug_v1_info output: listen address (peer id), ENR URI
get_waku_v2_debug_v1_version: node version
get_waku_v2_admin_v1_peers output: peers connected to, state and protocols

NagyZoltanPeter commented 1 year ago

I updated the description to match template. Couple remaining questions/suggestions:

I propose to scope this bounty to send message/subscribe/retrieve from relay+store only. We can scope the RLN registration in a subsequent bounty

You mentioned "subscribe" and get_waku_v2_store_v1_messages this seems incorrect. Please confirm we expect:

a) send message over relay with post_waku_v2_relay_v1_message b) subscribe to live incoming message over relay with regular call on get_waku_v2_relay_v1_messages c) do a store query to a remote peer using get_waku_v2_store_v1_messages

Let's prefer REST API over JSON RPC but I agree it's not blocking. @NagyZoltanPeter are the 3 methods listed available on REST API?

Yes, they are. Rest api spec is correctly mentioned in the description. May add store api: https://github.com/waku-org/nwaku/blob/master/waku/node/rest/store/openapi.yaml

a., post_waku_v2_relay_v1_message -> POST /relay/v1/messages/{topic} b., get_waku_v2_relay_v1_messages -> GET /relay/v1/messages/{topic} - download received messages from cache since last call POST /relay/v1/subscriptions - to suscribe DELETE /relay/v1/subscriptions - to unsibscribe c., get_waku_v2_store_v1_messages -> GET /store/v1/messages May add store api: https://github.com/waku-org/nwaku/blob/master/waku/node/rest/store/openapi.yaml

Rest Api also available for debug: https://github.com/waku-org/nwaku/blob/master/waku/node/rest/debug/openapi.yaml

alrevuelta commented 1 year ago

@fryorcraken Yes you are right. Only one thought

We can scope the RLN registration in a subsequent bounty

I would like to include RLN as well since its quite easy to do and right now we dont have a way to register a RLN membership without technical knowledge. In fact I would give prio 1 to this, because all the other features (eg publish message) require an RLN membership, so if we dont offer registration, how will people use it?

Note that this is focused on non tech savy users, so rln registration via cli, is not a valid option.

Should be trivial in js

const ethers = require('ethers')

const rln = new ethers.Contract(address, abi, w)
await rln.register(ethers.BigNumber.from(ethers.utils.randomBytes(32)), {value: v})

# Promt the user to sign the tx with metamask.
# Done.

alrevuelta commented 1 year ago

Adding another just released example of nodes creating UIs. https://lighthouse-blog.sigmaprime.io/Siren.html

fryorcraken commented 1 year ago

Adding another just released example of nodes creating UIs. lighthouse-blog.sigmaprime.io/Siren.html

Definitely a lot of inspiration (e.g. logs)

I would like to include RLN as well since its quite easy to do and right now we dont have a way to register a RLN membership without technical knowledge.

However we do not have a REST API to pass the RLN credentials, right?

Not sure if it makes sense to be able to restart a node with new command line argument from the interface or direct the user to change their docker file.

Shall we scope a new RPC API for RLN as part of the Waku network milestone?

alrevuelta commented 1 year ago

I would like to include RLN as well since its quite easy to do and right now we dont have a way to register a RLN membership without technical knowledge.

However we do not have a REST API to pass the RLN credentials, right?

Yep, we dont have that. But note that I was refering to just rln registration. rln registration can be done frontend<->smartcontract directly. So no api endpoint required. But ofc, you are right that then we need to load somehow this generated keystore to waku. A first naive approach could be to just rely on default values. Eg, default name for keystore is keystore.json and we can have the frontend save and mount the generated keystore.json into the right location. So for a first iteration perhaps we dont need rln rest api endpoints.

This second part can stay out of scope for the bounty, unless we have it ready in the rest side before someone takes this. But the above idea should be enough.

Shall we scope a new RPC API for RLN as part of the Waku network milestone?

Sure, just opened this to track it https://github.com/waku-org/nwaku/issues/1985. Unsure if we need it and the implications, so issue open for feedback.

fryorcraken commented 12 months ago

@alrevuelta I think it's fine to include an RLN component as described. I think for now, also ok to just have a keystore.json file store locally and then the user can be told to restart the docker passing a new argument (or maybe we modifiy docker compose to mount current working directory in docker and looking for a keystore.json file to use for RLN?).

Only blocking item is accessing the smart contract address from the nwaku node because I assume there is no REST API for that either:

It must use the contract address configured in the node

Or maybe we can make it work by having this config information in the docker compose and it's passed to both the nwaku docker and the webapp docker.

fryorcraken commented 12 months ago

This bounty is officially open for applications!

Do note that this bounty does contain few unknowns and it will take some back and forth to get it right.

alrevuelta commented 11 months ago

Only blocking item is accessing the smart contract address from the nwaku node because I assume there is no REST API for that either:

imho this should be done directly frontend<->blockchain. so no rest api endpoint would be needed.

fryorcraken commented 11 months ago

Only blocking item is accessing the smart contract address from the nwaku node because I assume there is no REST API for that either:

imho this should be done directly frontend<->blockchain. so no rest api endpoint would be needed.

How does the Frontend knows the smart contract address? Hardcoded?

alrevuelta commented 11 months ago

How does the Frontend knows the smart contract address? Hardcoded?

By now yeap, no big deal to have it hardcoded. With the time, we may add an endpoint that will return network metrics such as epoch time, rln contract, max message size, etc. But not a blocker for this.

alrevuelta commented 11 months ago

sine js-waku can't generate keystores compatible with nwaku, this https://github.com/waku-org/js-waku/issues/1600 is a prerequisite for the bounty.

fryorcraken commented 11 months ago

@alrevuelta I suggest we descope RLN and keep the bounty open. This will increase the chance of it happening. If a hacker is keen to get this done, most likely they'll be happy to tackle follow-up bounties.

alrevuelta commented 11 months ago

@fryorcraken indeed. Just removed the rln integration from the bounty.

lyrx commented 11 months ago

Hi,I might be willing to apply, but might also have some questions. So I would start with the react example from the examples repo and turn it into something that fits the requirements. I would also dockerize the solution and branch the waku-compose repo to add the react app as a new docker component running on port 3001. How does that sound for you?

alrevuelta commented 11 months ago

@lyrx approach sounds good thanks. I would start with a simple UI that allows you to publish a message via the REST api, then we can continue evolving it until fitting the requirements. Feel free to ask feedback inbetween and use our discord for support.

lyrx commented 11 months ago

Thanks for the quick answer. What would be the right Discord channel to ask questions related to this? ( I just joined your Discord server)

fryorcraken commented 11 months ago

Thanks for the quick answer. What would be the right Discord channel to ask questions related to this? ( I just joined your Discord server)

Just use our #support channel under the DEV category.

Please be sure to apply if you are keen to do the work: https://github.com/waku-org/bounties/#applying-for-a-bounty

Finally, as discussed in Discord:

So I would start with the react example from the examples repo and turn it into something that fits the requirements

This is not the way to go as the examples use js-waku, a JS Waku client

We are here asking to build a frontend for nwaku. Nwaku being the Waku client. The frontend should be interacting with nwaku using the REST API.

See description for Open API specs.

fryorcraken commented 10 months ago

Note: bounty changed. It was priced higher due to the RLN part which has now been descoped.

fryorcraken commented 9 months ago

done in-house

chair28980 commented 9 months ago

https://github.com/waku-org/pm/issues/100

waku-org / bounties