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

Status MVP: Status Core Contributors use Status Mobile #8

Closed
3 of 20 tasks
jm-clius opened this issue Dec 6, 2022 · 9 comments
Closed
3 of 20 tasks

Status MVP: Status Core Contributors use Status Mobile #8

jm-clius opened this issue Dec 6, 2022 · 9 comments

Comments

@jm-clius
Copy link

jm-clius commented Dec 6, 2022

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 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:

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

Issues

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

Basic peer management and nwaku implementation

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)

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

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

Filter and lightpush integrated dogfooding (may be descoped)

  • Who? ??
  • Estimated effort: ~2 weeks
@fryorcraken fryorcraken added this to Waku Dec 6, 2022
@jm-clius jm-clius added the RAID label Dec 8, 2022
@jm-clius jm-clius removed this from Waku Dec 12, 2022
@oskarth
Copy link
Contributor

oskarth commented Jan 13, 2023

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

@jm-clius
Copy link
Author

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

@fryorcraken
Copy link
Contributor

Is there a decision made regarding

Decide on lightpush/filter vs Relay for Mobile connectivity

@jm-clius
Copy link
Author

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
Copy link
Author

jm-clius commented Jan 19, 2023

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 fryorcraken changed the title Status Mobile MVP: Status Core Contributors use Status Mobile Status MVP: Status Core Contributors use Status Mobile Jun 15, 2023
@fryorcraken
Copy link
Contributor

fryorcraken commented Jun 30, 2023

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
Copy link
Contributor

weekly update

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

@fryorcraken
Copy link
Contributor

@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
Copy link
Author

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

@fryorcraken fryorcraken added E:2.1: Production testing of existing protocols See https://github.com/waku-org/pm/issues/49 for details and removed E:2023-light-protocols E:2.1: Production testing of existing protocols See https://github.com/waku-org/pm/issues/49 for details Epic Tracks a sub-team Epic. labels Sep 22, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants