Status MVP: Status Core Contributors use Status Mobile

[jm-clius]

Deadline: 10 Feb: focus for Status Communities is on Status Desktop.

High level requirement:

• 120-130 people continue using Status Communities over Waku v2 on Status Desktop
• 120-130 people start using Status Communities over Waku v2 on Status Mobile

Details

Client Diversity

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

Network Connectivity

• Desktop Clients are mostly online
  • Laptops on during working hours
  • Offline during night
  • Some app reboot
• Desktop Clients have a stable internet connection (WiFi + DSL/Fibre?)
• Mobile clients are mostly offline
  - Status App only loaded as needed on mobile
• Mobile Clients often have restricted/expensive internet connection (3G/4G). WiFi + DSL/Fiber when at home.
• For this MVP we assume that Mobile clients have similar connectivity (WiFi + DSL/Fibre) than Desktop Clients

Network Topology

• Fleet nodes provide store, lightpush and filter services
• Desktop clients provide lightpush and filter services and consume store services
• Mobile clients consume lightpush, filter and store services
• Only TCP transport is used.
• Desktop users connect to fleet and each other, Waku Relay is used:
  • Users are behind NAT devices.
  • Connections drops semi-regularly (see Network Connectivity)
  • Low upload bandwidth > low download bandwith for another user
  • Discovery needed to find users.
• Mobile users connect to the fleet and Desktop Clients for Filter and Lightpush. Filter and Lightpush is used for communication
• Mobile users connect to the fleet and each other, Waku Relay is used:
  • Users may be behind a NAT or on a restrictive/expensive connection
  • Connections drop regularly
  • Low bandwidth availability, high latency
  • Discovery needed to find service nodes

Details

• Confirm that Relay users can generally use the existing NAT traversal strategies (UPnP/PMP) for both libp2p connectivity and peer discovery (DNS/discv5)
• Confirm choice(s) and requirements for Relay users that cannot use existing NAT traversal strategies (set out below)

The following design options exist for Relay users that cannot use the existing NAT traversal strategies:

• Relay + Waku Peer Exchange: if most clients in the network are reachable and can therefore successfully be discovered, the few clients that can't, could discover random peers and make outgoing connections only using Waku Peer Exchange (at least in the meantime).
• Relay + Hole Punching + Other discovery method: see this summary. Requires AutoNAT, AutoRelay and a method to discover relay peers (libp2p rendezvous/libp2p kad-dht)

Roadmap

• Filter/lightpush protocol RFC revision
• Filter/lightpush alpha implementation in nwaku
• Filter/lighpush alpha implementation in go-waku/status-go
• At least 2 weeks of targeted dogfooding

Issues

• Waku Filter and Lightpush: Evaluation and improvement #5

Waku Store

Store Data Volume

• Assume higher, but similar order, data volume as during current dogfooding.
• Network traffic highest weekdays during European working hours

Store Query Frequency

• Assuming pattern defined in Network connectivity

  • Mobile queries likely higher per instance than Desktop due to more frequent app restarts
  • Mostly 72 hours queries (laptop off in weekend)
  • 30 days queries on occasional app reset

• peak of queries when app start at begin of work day. Monday highest due to weekend overlap. ~90 CCs in Europe.

• Need to understand total volume of queries with addition of Status Mobile clients

Store Query Format

• Status Client to provide list of exact store query formats to ensure that nwaku unit tests cover all scenarios (# of content topics, cursor +- timefilter, etc)

Store Protocol

Store protocol to be stabilised and normalised to Store v3. Nwaku to support both the existing v2 protocol and the improved v3 protocol.

Archive Backend

The SQLite Archive is reaching its upper bound. The addition of queries from Mobile clients would be at a rate that requires a more robust archive backend (PostgreSQL, as previously decided) that allows for parallelisation.

Furthermore, as reported in issues such as this one a mechanism for fault tolerance/redundancy is necessary for complete historical message persistence reliability.

Roadmap

• Confirm expected data volume/frequency/format
• Store V3 stabilisation and implementation (nwaku, go-waku)
• PostgreSQL archive implementation (nwaku, go-waku)
• Review PostgreSQL upper bound performance (from published benchmarks)

Issues:

• bug: inconsistent / missing messages in status.prod fleet nwaku#1400
• wakuv2: invalid messages not stored in Waku Archive status-im/status-go#3004
• Stabilize and normalize 13/WAKU2-STORE RFC vacp2p/rfc#552
• Waku Store Cache: PostgreSQL implementation #4

Peer/Connection Behaviour

• Peers mostly behave correctly
• Basic peer/connection management in nwaku: Networking MVP: Refactor + extend functionality nwaku#1353
• go-waku to implement basic peer/connection management arising from previous point as needed
• Tracking of peers with poor bandwidth/connectivity may be needed, or peer that cannot accept inbound connections.

Roadmap

• Basic Waku Peer/Connection management guidelines: Waku Peer and Connection Management #6
• Implement basic peer/connection management (nwaku and go-waku, as needed): Networking MVP: Refactor + extend functionality nwaku#1353

Issues

• Waku Peer and Connection Management #6
• Networking MVP: Refactor + extend functionality nwaku#1353

Bridging

• Status Client to confirm that v1<> v2 bridging remains disabled/out of scope

Peer Persistence

• Status Client to specify whether discovered peers be persisted across restarts (NB to remember gossipsub mandatory backoff period here)?

Miscellaneous open questions

• What role (if any) will Status Web be playing for this milestone?
• Who will be assigned to each of the above open tasks?

Consolidated roadmap view

The most important/largest work items extracted from above:

Store v3 RFC and nwaku implementation

• Who? @LNSD
• Estimated effort: 5 weeks

Filter and lightpush RFC revision and nwaku implementation

• Who? @jm-clius
• Estimated effort: 8 weeks

Basic peer management and nwaku implementation

• Who? @alrevuelta
• Estimated effort: 8 weeks

Decide on lightpush/filter vs Relay for Mobile connectivity
(See connectivity discussion to understand requirements to use Relay. ~70% of clients need to operate in environment where they can meet this connectivity requirement.)

• Who? @cammellos and Mobile team
• Estimated effort: ??

PostgreSQL archive implementation (nwaku)

• Who? Mobile team (@cammellos to assign resource)
• Estimated effort: ??

PostgreSQL archive implementation (go-waku)

• Who? @richard-ramos
• Estimated effort: ??

Filter and lightpush go-waku implementation (may be descoped)

• Who? @richard-ramos
• Estimated effort: ??

Test discovery mechanism for circuit-relay peers (go-waku)

• Who? @richard-ramos
• Estimated effort: 1 week

Filter and lightpush integrated dogfooding (may be descoped)

• Who? ??
• Estimated effort: ~2 weeks

[oskarth]

Is this issue up to date? Do we have a rough sketch of the milestone after this?

[jm-clius]

Next milestone still to be set. This issue is up to date and items tracked/synced on during weekly update meetings.

[fryorcraken]

Is there a decision made regarding

Decide on lightpush/filter vs Relay for Mobile connectivity

[jm-clius]

There has. For this MVP it will be Relay-only. I'll update the milestone. I don't want to postpone the work on redesigning filter protocol to be postponed any further though, so I'm keeping it within this timeline. cc @cammellos

[jm-clius]

I've updated this MVP issue to reflect that filter and lightpush will not be used and that Mobile Clients:

1. will initially only use Relay
2. will do so under similar connectivity conditions than was assumed for Desktop (i.e. mostly from home WiFi, fair bandwidth availability, similar NAT traversal capabilities, etc.)

This is my conclusion from Waku e2e discussions. Will appreciate a confirmation of my understanding here. cc @cammellos

[fryorcraken]

Filter and Lightpush will be used by Status Mobile after all. Integration of Filter and light push has started in the Status mobile app. Description updated.

However, it hasn't been clarified whether Status Desktop clients will provide filter and light push services.

[fryorcraken]

weekly update

Light push and filter protocols are available in Status Mobile and Desktop. Some light dogfooding has started.

[fryorcraken]

@jm-clius I believe we can close this issue and ad-hoc track any issue raised by Status when dogfooding Waku on mobile or desktop with light push/filter, WDYT?

[jm-clius]

Indeed. Closing, as main tasks completed and integrated functionality being dogfooded.