roadmap/2023-09-18.md at 203ab4a0e5017b9045ec1125ee8712db1e500368

5.2 KiB

Raw Blame History

title

Epics

1.1 Network requirements and task breakdown {E:1.1 Network requirements and task breakdown}

achieved: Further specifications added for RLN. Merged and published first version of RFC
next: Define first launchable (sub)network for Devconnect.

Docs

Advanced docs for js-waku

achieved: added guide for local development with nwaku

Node operator doc - cloud and advanced options

achieved: added guide on advanced nwaku and WebSocket configurations
next: add guide for enabling node monitoring

Research

RLN Key Benchmarks {E:3.2: Basic DoS protection in production}

achieved: benchmark rln, see issue with report.

nwaku

feat: HTTP REST API: lightpush {E:REST API service node}

achieved:
next: LightPush REST endpoint will be implemented fully and put on PR review
blocking:

bug: wrong user_version in sqlite database that blocks the run of a Waku node {bug}

achieved: bug fix that prevented a Store nwaku to start if the SQLite db was created with versions [0.14.0 - 0.18.0]

feat: Autosharding API for (relay) subscriptions {E:1.2: Autosharding for autoscaling}

achieved: many PR fixes,
blocker: explicit subscriptions in js-waku tests

chore(rln-relay): Requirements to consider RLN ready (non experimental) {E:3.1: DoS requirements and design}

achieved: waku rln is not an experimental feature anymore, and is part of nwaku code base. from now on experimental features are hidden behind a flag and not in different build

chore: do not advertise multiaddr with port 0 {bug}

achieved: tested two different solutions: updating the port with an addressMapper, and not allowing the user to use port 0. Analyzed and discussed technical implications of both solutions. Initially followed decision to proceed with 2nd solution for now, with intention of implementing the first solution in the future.
- Opened a draft PR and updated tests for the solution of not allowing the user to choose port 0.
next: after further feedback received today, we have to complete the discussion of how to move forward and either review and proceed with current PR, or plan and implement solution that updates all the data structures consistently across the node

feat: HTTP REST API: Filter support v2 {E:REST API service node}

achieved: Filter v1 & v2 REST API endpoints merged to master
next: LightPush REST endpoint

chore: update resolved enr ip when using dns4-domain-name flag {enhancement}

achieved: implemented solution that does DNS IP resolution during node bringup when no external IP is found but a DNS address is provided.
- Validated and tested "happy paths" of the solution, raised draft PR and got feedback about the solution
next: discuss and define the system's behavior on errors, implement error handling and adding tests for this feature.

js-waku

Maintenance {E:2023-qa}

achieved: added logs, investigated issues reported
next: approach reported issues, add preventative measures

Cover Several Environments As Part of Testing {test}, {E:2023-qa}

achieved: got reviews on playwrights tests
next: maybe add bounty, check Karma testing

go-waku

feat: discovery & peer management for static shards {E:1.4: Sharded peer management and discovery}

achieved: Update WakuPeerStore to store pubSubTopics for a peer.
next: Sharded Peer Management considering static sharding for Status communities.

RLN enabled by default {E:3.2: Basic DoS protection in production}

achieved: isReady verif in /health endpoint, make RLN available in service nodes and library usage by default, update docs and docker image, use zerokit 0.3.4, allow running service node with no RLN credentials
next: bandwidth validation, subcommand to list credentials