[BOUNTY] Build dApp of Your Choice Using Waku (Decentralized Communication) and Svelte

[fryorcraken]

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.

The JavaScript implementation of Waku, js-waku, enables web apps to utilize the Waku network for off-chain message transmission.

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.

Bounty

This bounty specifies 3 deliverables, all needed to consider the bounty complete. Partial delivery of the bounty will not make you eligible for the prize. The deliverables are:

1. A simple web app written using Svelte
2. A post on your blog to guide a reader through building the web app.
3. A tweet thread explaining how your web app works and leverages Waku for private, decentralized communications.

The bounty aims to inspire developers to build applications using Waku. This is why the web app's nature is up to the hacker. However, to push for creative use of Waku, we will not accept chat apps or chat features using Waku.

Impact

The web ecosystem has a number of frameworks that each have different pre-configured bundler. To ensure a smooth dev ex for all web developer, it is best to not only test @waku/sdk against the last version of each framework but also provide examples on how @waku/sdk can be used with concepts unique of said framework (e.g. React Components).

It is difficult to have expert of all frameworks in a team, so best to outsource this to the community.

Deliverables

(1) Web App

Build a web app using {web framework}.

Acceptance Criteria

You must fulfil all the criteria below to consider the bounty valid:

• Must use best and idiomatic practices for Svelte.
• Must use the latest stable version of Svelte and @waku/sdk
• Must be a frontend only, browser web app (no backend, no NodeJS, no SSR, no lambda function otherwise it's not decentralized).
• Must not be a chat app or use Waku for chat messages. Be creative!
• Must use Waku for a core communication feature.
• The web app must be deployed on IPFS or permissionless decentralized storage solutions.
• In addition to that, you are free to host the website on a web server of your choice, such as GitHub pages (not mandatory)
• All code must be licensed under MIT+Apache2.0.

Please describe your idea as part of the application to ensure your submission will fulfil the criteria.

We may add high-quality submissions to our example repo.

(2) Blogpost

Write a blog guide that takes a reader through building your web app. The reader should be able to build a working web app by following your guide.

We recommend building a simple web app to make the guide easy to write and read.

The blog post must be licensed under CC0.

High-quality guides maybe be edited and added to the Waku docs at https://docs.waku.org/.

Acceptance Criteria

We prefer moderate-length articles, ideally between 1500 to 3000 words (excluding code). While not mandatory, we strongly encourage you to adhere to this guideline.

When relevant, reference concepts and definitions from our documentation (https://docs.waku.org) and provide a link to our community (https://docs.waku.org/community) for additional assistance.

Avoid submitting articles you have already published or have a high plagiarism score to existing ones.

(3) Twitter thread

Post a Twitter thread from your Twitter account that describes how the web app uses Waku.

For example, if you build a tic-tac-toe game, describe how your web app finds another player using Waku and then exchange the moves over Waku.

Acceptance Criteria

• The thread must tag the @Waku_org Twitter account.
• The thread must explain how Waku is enabling this use case/app.

Resources

Learn more about Waku at https://docs.waku.org/. Join our Discord to get support at https://discord.waku.org/. Various examples available at https://github.com/waku-org/js-waku-examples/.

[5war00p]

Plan

Project title: Real time updates for token approvals Description: When user approves any token for a specific bridge contract then UI should reflect according by listening to the Waku topic.

Steps:

1. Frontend subscribes to the Waku topic (say /bridgeAgg/1/across-approvals/proto)
2. Backend (Logic) will request to the smart contract (external) to verify the approvals on x interval
3. Backend (Logic) Pushes updates to the Waku topic (/bridgeAgg/1/across-approvals/proto)
4. Frontend will filter and re-render based on the updates

Sequence diagram:

Note: Backend means the Logic that requests to the external resources and pushes to the Waku not the serverside stuff.

Track Record

• Full Stack exprience with DApp - Concept of Multi Bridge Aggregation
• Had experience with open-source contributions
• Freenlancer - Upwork

Timeline

Estimated: 2 weeks

[fryorcraken]

What tech will you use for the backend?

Please fill in the typeform

Looks good on my end but we need legal to review applicaiton.

[5war00p]

So, I'm thinking to use one of these:

• A fetch call with setInterval
• useSWR revalidatation on Interval
• tanstack-query's refetchInterval

[5war00p]

@fryorcraken Also, submitted the form

[5war00p]

Also, backend means it's just fetching & filterat logic segregation. Will use javascript/typescript only end of the day.

[fryorcraken]

Bounty assigned to @5war00p

@5war00p application approved, you can start the work.

Please remember that blogpost and Twitter must be delivered to complete the bounty and get the reward.

[5war00p]

Hey @fryorcraken, here is the demo video for the DApp that I wrote using waku. The goal is to achieve lie updates for tokens w.r.to Hop bridge smart contract. Video shows intial approval state of 6 tokens and by unapproving MATIC, the UI will reflect the button state without reloading. This had waku setup internally where client subscribed to topic and filters message and updates svelte store value, which re-renders the button compoenent.

https://github.com/waku-org/bounties/assets/57614947/0590e15c-acd9-4a2f-bdd0-57f15a086426

[5war00p]

@fryorcraken Here is the updated video with toast messages: https://www.loom.com/share/092b5c5bc0394ce5911c629fb85f9167?sid=a179abeb-f1fb-46f7-9bb8-6278e4d9b2ee

[5war00p]

@fryorcraken Here is the video for multiple windows: https://www.loom.com/share/11f29b93178f46ed807a208b8cd10b14?sid=9028aa88-30ae-41dd-bb2c-8b487d8c12f2

[5war00p]

Here is the repo link: https://github.com/5war00p/bridge-token-approvals

[vpavlin]

My thoughts:

• [x] Can you add more context to teh README in your repo? So that people finding it actually get a better idea what is it for? Maybe also embed the video you recorded?
• [x] It would be good to explicitly say the app only works on Polygon and for Hop Protocol (assuming that's the case based on the list of tokens.ts):)
• [x] I am missing some indication that the app is connected to Waku - since to establish the connection takes some time, I'd like to see that I am connected before I hit the approve/unapprove buttons
• [x] I don't think the app works for me:D I run it locally in 2 tabs, but
  1. I never see a success notification (the TX passes)
  2. The time & date never changes + it seems like in my version of code it only prints the new Date() on load, not actually reflect the last update?
• [x] you can set ephemeral: true in createEncoder in waku/index.ts since you do not use Store protocol and it does not make sense to cache the messages by the network
• [x] it would be good to show the connected address as I have many in Metamask:) Especially since you store the address and use it later, it's gonna make for strange UX
• [x] in receiver.ts you are actually using subscribe incorrectly - subscribe returns unsubscribe function, so you subscribe twice there - first on the line 24 where you declare and initialize const unsubscribeTopic and then when you actually call subscribeTopic in ConnectMetaMaskWallet.svelte - you should capture return from filter.subscribe and then use that to unsubscribe

To be honest, I have never used Vite and Svelte, but I tried to add a few console.log in places of interest around Waku setup and they have not been executed:D

Is current main up to date?

[5war00p]

Yes, its the master branch has updated code. I will update the readme that explains what actually app does (which bridge and on what chain). I will update according to your suggestions.

Regarding date update currently the default state will be current time - which is why on reload you are seeing the new Date(). Will update that from localStorage so that it makes sense.

Also, w.r.to waku connected or not, can I use node.isStarted(), but I also need peer connections then only sending and receiving works right? Can I use node.connectionManager.getPeersByDiscovery() to get peers connected or not?

[5war00p]

Here is the updated code: https://github.com/5war00p/bridge-token-approvals/blob/master/README.md

Loom: https://www.loom.com/share/8e52ac7ffffa44d4adc7ce869d315f6d?sid=6c05627b-90ea-4e49-b78a-65780e22c0c2 Deployed Url: https://bridge-token-approvals.vercel.app/

Added Loom video and Deployed Url in readme too.

[5war00p]

@fryorcraken Here is the blog content that I created for this project: https://github.com/5war00p/bridge-token-approvals/blob/master/docs/blog.md

Waiting for review and feedback

[vpavlin]

Awesome, thanks a lot for clearing my list up there! I did another round of review and I have 2 more issues - one is a nitpick, but another one basically make the app unusable in any real world scenario, so I'll insist on fixing that one:)

1. My MetaMask was connected to Ethereum (chainId: 1) instead of Polygon, so the app threw into console when I tried to approve: getTransactionError.ts:44 Uncaught (in promise) TransactionExecutionError: The current chain of the wallet (id: 1) does not match the target chain for the transaction (id: 137 – Polygon). - not sure about Viem, but other web3 libs have ability to suggest network change if the MM and app network do not match - can you check it?

2. For the bigger issue - the app does now use wallet address in anyway when posting data to Waku and reacting to it. That's a problem because since all running instances get the message, they will all react to it - regardless which address is connected. So it is necessary to add address to the payload and then check if the message is actually for the given instance (i.e. has that wallet connected.). I tested it by connecting from my laptop and my phone (different address connected on either) and then I approved tokens on my laptop, but the change was also reflected on my phone.

In real world, you'd ideally also sign (well and encrypted:) ) the message and verify that it was signed by that wallet, but that is not really crucial for the demo app.

I am sorry I haven't realized this before:(

[5war00p]

Pointed very good ones.

1. My bad, I completely forgot about that and will add that check and suggest switch.

2. I think it's because of the Waku topic, if we add the wallet address into topic then as you said only connected wallet clients will receive the updates.

[vpavlin]

2. I think it's because of the Waku topic, if we add the wallet address into topic then as you said only connected wallet clients will receive the updates.

That is definitely one option how to solve it! The other option is to just add address to payload, let every instance get all the notification, but only the one where the wallet is connected would take it into account - this would be (IMO) the right solution because it provides a bit more privacy as all the messages travel on a single content-topic (although, obviously with plain-text messages, there is no privacy there:) ).

But I will lieave it up to you to pick the solution, both are perfectly acceptable!

[vpavlin]

FYI, I went over the blog post and proposed some small changes and typo fixes - let me know what do you think in the PR:

https://github.com/5war00p/bridge-token-approvals/pull/1/files

[5war00p]

2. I think it's because of the Waku topic, if we add the wallet address into topic then as you said only connected wallet clients will receive the updates.

That is definitely one option how to solve it! The other option is to just add address to payload, let every instance get all the notification, but only the one where the wallet is connected would take it into account - this would be (IMO) the right solution because it provides a bit more privacy as all the messages travel on a single content-topic (although, obviously with plain-text messages, there is no privacy there:) ).

But I will lieave it up to you to pick the solution, both are perfectly acceptable!

Got youu. Let's do as you suggested. Also I will add both the solutions in the blog.

Let me know do we have any scheduled clearance of abandonded Waku topics, so that will add that in the blog while explaining solutions.

[5war00p]

1. My MetaMask was connected to Ethereum (chainId: 1) instead of Polygon, so the app threw into console when I tried to approve: getTransactionError.ts:44 Uncaught (in promise) TransactionExecutionError: The current chain of the wallet (id: 1) does not match the target chain for the transaction (id: 137 – Polygon). - not sure about Viem, but other web3 libs have ability to suggest network change if the MM and app network do not match - can you check it?
2. For the bigger issue - the app does now use wallet address in anyway when posting data to Waku and reacting to it. That's a problem because since all running instances get the message, they will all react to it - regardless which address is connected. So it is necessary to add address to the payload and then check if the message is actually for the given instance (i.e. has that wallet connected.). I tested it by connecting from my laptop and my phone (different address connected on either) and then I approved tokens on my laptop, but the change was also reflected on my phone.

Hey @vpavlin pushed code for both the suggestions/fixes

Also, merged the PR for the blog content. Updated the conclusion, please do re-review the conclusion and issues fixes and let me know the feedback

[vpavlin]

Awesome, yeah, the app now works as advertised and expected:) Thanks for merging the PR:) @fryorcraken I am good from technical perspective in context of what we agreed upon!

[5war00p]

Coool. I will proceed with twitter post content and will comment here once its ready so that one of you can review.

[5war00p]

@fryorcraken @vpavlin Here is the Twitter thread content:

Thought of elaborating but twitter limits total no.of words/characters.

[fryorcraken]

@fryorcraken @vpavlin Here is the Twitter thread content:

Thought of elaborating but twitter limits total no.of words/characters.

Could you elaborate on the architecture by using a Twitter thread?

[5war00p]

@fryorcraken @vpavlin

Here are the published content details:

Medium Blog: https://medium.com/@maddisaiswaroop/the-intro-119a57ddb30b Dev Community Blog: https://dev.to/5war00p/building-resilient-dapps-svelte-and-waku-in-action-2mhf Twitter Thread: https://twitter.com/5war00p/status/1719602782192406574

[fryorcraken]

Thank you @5war00p ! We will proceed with reward next week.

[fryorcraken]

Bounty paid

[5war00p]

Thanks for the bounty! 🤠