Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Defining dogfooding webapps #1784

Open
fryorcraken opened this issue Jan 12, 2024 · 0 comments
Open

Defining dogfooding webapps #1784

fryorcraken opened this issue Jan 12, 2024 · 0 comments
Labels
enhancement New feature or request

Comments

@fryorcraken
Copy link
Collaborator

fryorcraken commented Jan 12, 2024

This is a bug report/feature or change request/support request

Problem

Follow-up of waku-org/examples.waku.org#275

@waku-org/js-waku-developers needs to define a small number of dogfooding webapp in lab.waku.org that enable:

  • dogfooding of new features, APIs and library
  • handover to Docs & Dev Rel of the feature for documentation and Dev Rel asset creation purposes.

Also note that it may interesting to unit test this small set of example to ensure they do not break as they will be critical to deliver any new feature.
There is already some work done in this direction

name: Playwright tests
but web-chat might not be the best choice.

Proposed Solutions

To avoid unnecessary and duplicate effort, the set of dogfood web app in lab.waku.org should be minimal and demonstrate as many API as possible.

In rough term of API to be covered:

  • Node creation, usage of RLN and autosharding with default bootstrap and peer discovery
  • Usage of req-res protocols: store, light push, filter
  • encryption and signature: ECIES, AES, noise
  • Other SDKs: @waku/react

Proposal: have two examples.

  • Very simple React app that demonstrate usage of @waku/react
  • Web app that demonstrate usage of most API listed above.

For the Web app, I recommend the usage of the notes web app as it can allow you demonstrated req-res protocol usage but also encryption:

  • When creating a note or using the app, user creates a new ECIES keypair as identity for the note
  • A note is always signed by owner of the note, signature is verify by reader to confirm original author (from oldest note they can retrieve) does a note update
  • note are encrypted using AES (symmetrics), symkey is included in URL passed to share a note

Potentially, noise-js could also be demonstrated: Alice links her browser phone to her browser desktop instance via noise.
When doing a note update on her phone, the desktop receives the note update via noise channel and proceed with signing it and propagating it to the network. This demonstrated how Alice can pair devices without copying private keys on other devices.

Notes

Feel free to edit this description once you agreed on the solution.

Some liveness is also necessary to easily spot disconnection, etc. I would recommend that when viewing a not, the page is automatically refreshed if a message with an update on the same note is received.

@fryorcraken fryorcraken added this to Waku Jan 12, 2024
@danisharora099 danisharora099 moved this to Triage in Waku Jan 17, 2024
@chair28980 chair28980 moved this from Triage to To Do in Waku Jan 24, 2024
@chair28980 chair28980 added the enhancement New feature or request label Jan 24, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
Status: To Do
Development

No branches or pull requests

2 participants