Status MVP: Multiple Communities + Token Gating + Status Web

[fryorcraken]

Deadline: 31 Mar 2023

High level requirement (Status):

• Start Dogfooding of Token Gating functionality on the Status CC community
• Other Logos projects (Codex, Nimbus, Vac, etc) switch to using Status
• Instances of Status Web with Token Gating functionality used for Logos and Status CC

Impact on Waku:

• Traffic increase due to more activity
• May expect slight increase of user
• Token Gating: no impact?
• Status Web usage: more light client protocols being used, this can be a major impact if light client protocols are not being used as part of Status MVP: Status Core Contributors use Status Mobile #8

Details

Client Diversity

• 150 users use Status Desktop
• 150 users use Status Mobile
• 150 users use Status Web

Note1: at a given time, it is not expected that a user would use all clients at the same time.
Note2: there may be an increase of users as some Status CC may not have migrated to Status yet as they are using a different Discord Server
Note3: Usage of Status Web may be privileged by Status CC that could not use Status Desktop. We could assume that most Logos CC will use Status Web.

Network Connectivity

• Status Web is expected to use light client protocols (filter, light client, store), they need to be served.
• Status Web can only connect via secure websocket with a valid, not self-signed certificate.
  • Do we want to support inbound Status Web connection in Status Desktop?: SSL + WS + DyDNS
  • Should we expect 100% Status Web nodes to connect to bootstrap fleet? What is the max connection setup on those nwaku nodes?
  • Should only Status fleet be used for store protocol, and a mix of nodes for light push + filter?
  • Do we want to explore WebRTC Direct? Web connects to Desktop via WebRTC Direct
    • go-waku is ready to accept incoming WebRTC connections (TBC)
    • WebRTC handshake would need to open over Waku, using a wss connection to a fleet node
    • WebRTC of Waku PoC is in progress and relies on noise handshake: WebRTC Exploration js-waku#20
  • WebTransport is the long term solution but only supported in Chrome. Need to review libp2p readiness.
  • Do we need to start extending operator adoption so that nodes than supports wss connections can be added to the network and discovered by Status Web via discv5 + peer exchange? This may be an option for filter+lightnode backup (with primary filter/lightnode/store served by Status fleet)

Network Topology

• Fleet nodes provide store, lightpush and filter services
• Desktop clients provide lightpush and filter services and consume store services
  • This assumes WSS support with non-self signed certs in Status Desktop
• Web clients consume lightpush, filter and store services
• Only WSS is supported by Web clients
• See pending questions from Network Connectivity

Roadmap

• Review impact of token gating on Waku (assumed none).
• Review metrics requested by Status Web Waku requirements status-im/status-web#310 (comment)
• Light Client Protocols readiness (to be updated depending on scope of Status MVP: Status Core Contributors use Status Mobile #8)
• Understand connectivity picture with Status Web in scope (wss + valid cert only)
• Need to have a better picture of expected usage of Status Web (scalability of incoming connections on the fleet).

[rymnc]

hey @fryorcraken is there some documentation on token gating's implementation? It is difficult to tell the impact of it upon Waku without that.

[fryorcraken]

I don't think it's defined at this stage. Cc @John-44 @cammellos