Waku requirements

[felicio]

What

• What protocols are you using? As you are aware, I am also refactoring js-waku APIs to make it more modular. I have actually improve store query from js-waku too. What else is needed?
• Relay? Not really scalable see https://github.com/waku-org/js-waku/issues/905
• Light push? Filter? What kind of expectations do you have? For a given web client, what message rate? how many content topic would one subscribe too, etc?
• What about encryption/decryption? are the API fitting purpose? Do you need better management of promises (subtle crypto calls)?
• What abut connection management? Any challenges so far?
  • [https://discord.com/channels/624205794384281629/1019203728701661274/1021967254876856371 (e.g. discovery)]
• [other]

– @fryorcraken

When

~~- After MVP~~

[fryorcraken]

• After MVP

Is the MVP the 30 September deliverable?

[prichodko]

I hope this will mark the beginning of the conversation to fix the issues, align the expectations or find workarounds.

The current implementation is built on top of Relay and Store protocols. We are aware of Relay's potential scalability issue. There is also a draft pull request experimenting with other protocols. During today's call, @fryorcraken mentioned that Lightpush + Filter should be a preferable combination. A written explanation would be appreciated.

Following is the list of Status Web MVP requirements with the links to the code that Status Web uses js-waku for. Also, I like to think about two phases that better illustrate the implications for end-user – non-interactive and interactive.

Non-interactive

The UI shows only the loader and is not interactive for the user. Ideally, this phase would not take longer than 3 seconds to make it feel fast and responsive.

• Establishing connection
  • https://github.com/status-im/status-web/blob/main/packages/status-js/src/client/client.ts#L76-L87
  • <1s
  • long-lived connection should stay alive (we experience random disconnections)
• Fetching the community description
  • uses Store protocol
  • https://github.com/status-im/status-web/blob/main/packages/status-js/src/client/community/community.ts#L94-L107
  • <2s

Interactive

We have basic information about the community, such as name, list of chats, and members. Users can perform actions, such as accessing chats or sending messages.

• Observing all chats for new messages
  • uses Relay protocol
  • https://github.com/status-im/status-web/blob/main/packages/status-js/src/client/community/community.ts#L143-L149
  • <1s
  • We experienced when sending a message from desktop to web over status.test took 9 minutes to arrive. This is not a very constructive feedback, but shows that this needs to be addressed.
• Fetching chat history
  • uses Store protocol
  • https://github.com/status-im/status-web/blob/main/packages/status-js/src/client/chat.ts#L196-L215
  • <3s

Store node requirements

• Node store duration should be 30 days
  • nwaku was recently decreased to 14 days due to: Hosts are running out of disk space.
• All store nodes should receive all messages
  • Currently connecting to different nodes can return different messages.
  • We can see in Grafana that number of messages differ significantly between nodes
    • 
• Nodes should store unlimited amount of messages
  • go-waku store capacity is unlimited (https://github.com/status-im/infra-go-waku/blob/947b80fa4cd00ede1851ac392143813002624106/ansible/group_vars/go-waku.yml#L35)
  • nim-waku store capacity is currently unknown
    • config was recently updated
    • either it's unlimited or one of this or this configs apply

Post MVP

go-waku feature parity

Recently, it has been suggested to use go-waku nodes when we were experiencing difficulties with nwaku nodes, however according to Franck's message that may not be the best idea:

if you status web hits a go-waku node for a store query we don;t know what kind of performance you'd hit. We do not have go-waku store performance on the roadmap. You may want to be careful with that.

Bridge

Currently the bridge has been turned off for production fleet, however we are worried that it does not reflect the real world scenario. So releasing it in this state may create confusion for people installing desktop or mobile now.

[fryorcraken]

During today's call, @fryorcraken mentioned that Lightpush + Filter should be a preferable combination. A written explanation would be appreciated.

Waku Relay does not scale in the browser, as discussed in https://forum.vac.dev/t/waku-v2-scalability-studies/142/9 An issue tracks work to improve relay scalability in the browser: https://github.com/waku-org/js-waku/issues/905

Filter and Light Push does not face this scalability problem as they are simple request/response protocols.

Do note that the some of relay's privacy gains are loss when using the store protocol, hence there is little drawbacks in switching to filter+light push in your use case.

It also save bandwith as relay receives and forward any messages seen, whereas with filter you only receive messages of the content topics you have subscribed to.

[fryorcraken]

Thank you for that. I shall digest it and provide some feedback: education material, issues tracking necessary work, questions, etc.

[fryorcraken]

Attack plan:

1. Look at the few requirements above
2. Break them down in Waku terms
3. Describe the sequence of events (e.g. connect to node = DNS query + libp2p connection) to state expectations.

Some information is outdated (filter should be used, not relay).

In the case of Waku Store, would be good to check usage of store by status-web and whether it's optimal (in terms of sqlite queries, nwaku is optimized for specific queries via index and query plan(?)).

[chair28980]

@fryorcraken how should we move forward with this issue? Is it still relevant for pickup?

[fryorcraken]

This was an earlier attempt to understand what Status needed for Waku. The attempt has now been merged with the Chat SDK team effort.

Once Status design to use Waku has been decided for the app launch, then we can work closely with the Status web team to clarify how this affects the browser.

Currently, the Status design is still moving and hence it is difficult to provide accurate information until it is pinned down.

[weboko]

Moving to Icebox as per previous comment.

[fryorcraken]

I would suggest to close this until Status Web comes back in scope. At which point we can review the requirements.