Roadmap issue: Status and the Waku Network

[jm-clius]

Background

For more background on the public Waku Network MVP, see #1. This issue provides an overview of the proposed roadmap and parallel tracks to achieve this end goal.

For a graphic representation of the roadmap and epics, see the Miro board

Tracks

Individual epics are roughly sorted under tracks that can in most cases be tackled in parallel, although there are some interdependency between tracks as qualified below.

1. General Track

This tracks the main body of work to build an autoscaling, autosharded network and provides the foundation for the other tracks.

Epic 1.1: Network requirements and design

Goal: 31 Aug 2023

This tracks the work necessary to determine the specifications for a public Waku Network and a rough design to achieve this. The deliverable of this epic is to answer questions such as:

1. How many shards to we want to support initially? Do we know how to increase this in future?
2. What is the reasonable bandwidth expectation per shard?
3. What is a reasonable message rate expectation per shard?
4. What is a reasonable number of publishers per shard?
5. What is a reasonable max message size for the shard?
6. What membership mechanisms and limits should we set and should this be done on a per-shard basis?

Epic 1.2: Autosharding for autoscaling

Goal: 30 Sept 2023

This epic tracks designing and implementing an autosharding strategy based on content topics and the design requirements established in 1.1. The first phase would likely be to launch with a limited number of shards (perhaps no more than 128?). More shards can be added as the network grows organically, perhaps using some "generation ID", that allows opening more shards with successive generations.

Epic 1.3: Node bandwidth management mechanism

Goal: 31 Oct 2023

As the autosharded public network grows and traffic increases per shard, we want to provide some bandwidth management mechanisms for relay nodes to dynamically choose the number of shards they support based on bandwidth availability. For example, when the network launches, it's reasonable for relay nodes to support all shards and gradually unsubscribe from shards as bandwidth increases. The minimum amount of shards to support would be 1, so the network design and DoS mechanisms (see Track 3) would have to provide predictable limits on max bandwidth per shard. We could also envision a bandwidth protection mechanism that drops messages over a threshold, but this will affect the node's scoring so should be carefully planned.

Epic 1.4: Sharded peer management and discovery

Goal: 30 Nov 2023

This epic tracks work necessary to allow applications to interact with shards in a transparent manner. Relay nodes should preferably be subscribed to the shards carrying the content topic(s) the application is interested in. Where this is not the case, the application should be able to interact with service peers within the shards it's interested in via a peer management scheme. The peer manager should be tracking peers from all public shards or be able to discover such peers on demand.

Epic 1.5: Launch and dogfood integrated public Waku Network MVP

Goal: 31 Dec 2023

Combining outputs from all other tracks and epics, launch and dogfood the Waku Network MVP as set out in #1 by the end of the year.

2. Service protocols track

This tracks work necessary to make service protocols, specifically filter, lightpush, peer-exchange and store work in a public network and in a decentralised manner.

Epic 2.1: Production testing of existing protocols

Goal: 31 Aug 2023

All service protocols are currently in alpha/beta implementation phase and have undergone significant changes aimed at delivering the Status MVP. Filter protocol, for example, has been redesigned from the ground up, while a new PostgreSQL archive backend for the Store protocol has been added. Before building on these protocols, their use in a production environment must be properly dogfooded and hardened.

Epic 2.2: Sharded capability discovery for light protocols

Goal: 30 Sept 2023

Ability to discover peers providing filter, lightpush and peer-exchange services within the decentralised network. To the application this should present as a peer selection mechanism that translates content topics to underlying shard.

Epic 2.3: Basic distributed Store services

Goal: 31 Dec 2023 (dogfooded and integrated in 2024)

Ability to discover Store nodes that provide store services for specific content topics and time ranges and for service nodes to advertise their store services as such. This includes work to allow Store service nodes to only store messages for specific content topics/applications.

Epic 2.4: Basic design for service incentivization

Goal: post 2023

Once services can be provided in a distributed (if not fully decentralised) manner, we need to revisit previous ideas on incentivising provision of such services (e.g. using a service credentials approach). This will become a large research track on its own. Only the first step is tracked here to show how it relates to work for the public Waku network.

3. DoS Protection track

Epic 3.1: DoS requirements and design

Goal: 31 Aug 2023

This builds off the general specification phase to answer questions specific to DoS/spam protection in the public Waku Network. The deliverable is answer to questions such as:

1. What is a reasonable epoch size and rate design for the network? Should this be managed per shard or for the entire autosharded network?
2. What is a good initial, test membership mechanism and what is the roadmap to onboard more members?
3. Should we allow a certain amount of "free" traffic (without membership/proofs) on the network? How is this fairly managed and limited?

Epic 3.2: Basic DoS protection in production

Goal: 31 Oct 2023

An RLN mechanism implemented and productionised, which includes:

1. Initial membership mechanism (likely only for Status CCs and some trial users)
2. Rate limiting when specified bandwidth threshold is exceeded

This phase would include allowing applications to provide their own DoS protection mechanisms by opening a message validation API.

Epic 3.3: Membership for Status Communities

Goal: 30 Nov 2023

A mechanism to allow Community Owners to assign RLN membership to community members.

Epic 3.4: Production and memberships on mainnet

Goal: 2024

Expanding membership (and therefore high QoS access) of the public Waku Network to third parties and more community members. General membership that falls outside the targeted member groups may require a staking mechanism to be in place.

This may include a membership mechanism to allow Status users to "sign up" to use 1:1 chat with DoS protection.

For this epic, RLN contracts must be deployed to mainnet.

Further epics: Slashing, staking and incentivisation

Goal: 2024

Cryptoeconomic design to allow "full RLN" with staking, slashing and incentivisation of spam detection implemented. This follows the launch of the public Waku Network and extends beyond "basic" DoS protection.

4. Status Communities Track

This tracks epics performed by Status product developers for the rollout of Status Communities over Waku.

Epic 4.1: ~10 Logos internal communities

Goal: 31 Aug 2023

With the Status 10K MVP reaching feature-completeness, dogfooding of statically-sharded communities, with all the features designed around scalability of this model, must start in earnest. The suggestion is to start with a single Test Community, followed by a Status CC Community and then one for each of the existing Logos teams/communities (Vac, Waku, Codex, Nomos, etc.). Features such as Media Shards, Control Message sharding, etc. must be implemented and tested fully during this period.

Epic 4.2: ~100 statically-mapped communities

Goal: 30 Sept 2023 (and continuing to onboard more communities afterwards)

Inviting interested parties to move their communities to Status, with services such as store and bootstrapping fully provided by Status during this period. Specific static shards are assigned to each of these communities to allow Status to provide the necessary services until Community Owners (and members) can do so themselves using mechanisms introduced for Waku distributed services (see 2.3).

Epic 4.3: Open (permissionless) communities

Goal: 30 Sept 2023

Note: this work can be done in parallel to 4.2 to allow non-invited Status product users to test the beta community feature and start building their own community

This allows "anyone" to create a community, with some services provisioned by Status. This can be the mechanism for people creating communities via the app:

1. All communities created via this method uses the same shard (or group of shards).
2. All communities on this shard share the same DoS protection key. This is a weak form of DoS protection, but reasonable in a beta feature. Community relay nodes won't be isolated from spam on other communities. Light clients will be isolated from spam on other communities by only subscribing to traffic belonging to their own communities.
3. Status must provide a mechanism for permissionless communities that reach a certain size to be considered to receive their own shards with Status-provisioned services (similar to the process described in 4.2) and to have their data migrated to this new shard.
4. Services for permissionless communities should preferably be provisioned on a separately managed fleet. More shards can be provisioned when this becomes popular, but it should be seen as a beta-only feature and focus must remain on onboarding the 10-100 large communities on statically-mapped shards.

Epic 4.4: Open communities on public Waku network

Goal: 31 Jan 2024

Once the public Waku network has the following required features, open communities can move from their weakly-protected shared shards to the autoscaling public Waku network:

1. Bandwidth management mechanisms
2. Basic general DoS protection
3. Membership mechanism for Status Communities
4. Distributed Waku services (bootstrapping, Store, etc.)

Epic 4.5: Distributed Community services

Goal: 2024

Large/statically-mapped communities will continue operating on their own shards with Status-provisioned services for as long as Status can provide this service. Distributed Waku services will also allow these communities to provision their own Store/service/bootstrap nodes or make use of third party service providers.

Risks

1. The roadmap above is created without a formal design and may therefore overlook many details and risks that will affect the proposed goal dates.
2. Several items need to be completed (dogfooding, usage of static sharding, making Status protocol scalable, etc) before we can ensure that Waku Network's design, especially around bandwidth, maximum message rates and maximum message sizes will be sufficient for Status's Community requirements.
3. Many aspects of how the public Waku network will operate is still unclear. For example:

• How will applications interact with underlying shards? Applications will only define content topics which will transparently get mapped to shards.
• Do we need an extension of discv5 or other discovery mechanisms, given that we will need to discover peers belonging to different shards, provide different capabilities, etc.?
• How will we design bandwidth management mechanisms for nodes?
• The roadmap above does not include a key rotation/re-keying mechanism for Status Communities to prevent removed/blocked Community members to continue publishing on static shards (this is not a problem on the public Waku network, where a general DoS protection mechanism is planned).

[jm-clius]

Task breakdown

Below an initial task breakdown to achieve the epics listed in the issue description.

1.1 Network requirements and design

Task: Waku Network raw RFC

Single RFC that specifies the Waku Network. Some details that should be included:

• shard allocation (for gen0)
• content topic use; pubsub topic format
• rough overview of generations (and mentioning that this is mostly future work)
• use of Waku protocols and Waku Message, defaults and recommended services
• resource-restricted nodes
• RLN and membership configuration
• autosharding requirements (basic and potential future operation)
• bandwidth limiting mechanisms
• etc.

Owner: @jm-clius (with specific sections covered by relevant owners)
Priority: Critical for launch

1.2 Autosharding for autoscaling

Task: Autosharding specification

Note: This is already done.

Tracks the work necessary to design and specify the mechanism to hash content topics to the shards defined for the gen 0 network.

Owner: @SionoiS
Priority: Critical for launch

Task: Autosharding API for req-resp protocols

Note: This is already done in nwaku.

This tracks the work necessary in each client to provide API(s) to applications using req-resp protocols (store, lightpush, filter, etc.) with optional pubsub topic arguments. Each client should then use autosharding to determine the associated shards on behalf of applications. Note that underlying protocols should not be affected and each client implementation should locally populate pubsub topic fields with the shards hashed from content topics received via the API.

Owners:

• nwaku: @SionoiS
• go-waku: @chaitanyaprem
• js-waku: ??

Priority: Critical for launch

Task: Autosharding API for (relay) subscriptions

Currently the only way to manipulate a relay node's pubsub topic subscriptions is through an explicit subscribe call with the pubsub topic as argument or via static configuration when setting up the node. This task tracks work to add a subscribe method to relevant Relay APIs allowing applications to provide desired content topics as (relay) subscribe arguments, while the node translates those to relay subscriptions for specific shards. This task should involve a mechanism where an application is only notified of new messages on subscribed content topics, instead of all messages on the subscribed shards.

Owners:

• nwaku: @SionoiS
• go-waku: @chaitanyaprem
• js-waku: ?? (may not be necessary)

Priority: Critical for launch

Task: Autosharding protocol changes for req-resp protocols

This tracks work necessary to change req-resp protocol requirements for pubsub topic fields to be optional in wire specifications. This implies a spec change, changes to clients to use the simplified specs and changes to server-side Waku implementations to interpret client requests with no populated pubsub topics correctly.

Owners:

• specification: @SionoiS
• implementations:
  • nwaku: @SionoiS
  • go-waku: @chaitanyaprem
  • js-waku: ??

Priority: Not critical for launch (all main benefits of autosharding is already achieved via API changes)

Task: Autosharding - dogfooding

Once the critical parts for autosharding has been implemented, we should dogfood the end-to-end operation. This could constitute a soft launch of the Waku Network with the first traffic relayed on all new network shards, albeit without any DoS mitigation mechanisms in place. Specific things to test include reviewing how well autosharding works with sharded discovery and bootstrapping (mechanisms that were developed previously for static sharding).

Owner: @SionoiS
Priority: Critical for launch

1.3 Node bandwidth management mechanism

Task: Validation mechanism to limit "free traffic" on the network

This tracks the work to define and implement a relay validator that allows nodes to limit the amount of bandwidth they're willing to allocate for routing "free traffic". In this case, "free traffic" would be Waku messages with no RLN proofs.

Owners:

• specification: @vpavlin
• implementations:
  • nwaku: @vpavlin
  • go-waku: @richard-ramos
  • js-waku: ?? (may not be necessary)

Priority: Critical for launch

Task: Proper bandwidth metrics per shard

This tracks work to ensure we have proper metrics and network-wide dashboard available to monitor bandwidth usage per shard. This should also consider other types of metrics (e.g. number of applications/content topics per shard, node distribution, etc.)

Owner: @vpavlin
Priority: Not critical for launch

Task: Failsafe mechanism (guide) for BW limiting

This tracks work to guide node operators on how to configure third party tools on various platforms to set a hard limit on Waku bandwidth usage as a failsafe mechanism.

Owner: @vpavlin
Priority: Not critical for launch

Task: Dynamic subscribe/unsubscribe mechanism (or similar)

With autosharding, nodes' shard subscriptions (relay) are influenced by:

• initial static configuration (pubsub topic or content topics hashed to pubsub topics)
• runtime, dynamic subscription to content topics
  A useful feature may be a bandwidth management mechanism for relay nodes to choose dynamically the number of shards they support based on bandwidth availability. For example, when the network launches, it's reasonable for relay nodes to support all shards by default and gradually unsubscribe from shards as bandwidth increases, always preferring shards for which content topic subscriptions exist. If a node is configured with very restricted bandwidth, the relay subscriptions may even "convert" to a filter subscription, allowing the node to opt out of relay automatically.

Owner: @vpavlin
Priority: Not critical for launch

1.4: Sharded peer management and discovery

Task: Peer discovery with dynamic shards as dimension

Tracks work necessary to ensure that nodes can filter discovered peers according to the shards the node is currently subscribed to and for the node to update its own discoverable ENR every time its subscription set changes.

Owners:

• nwaku: @SionoiS
• go-waku: @chaitanyaprem
• js-waku: ?? (may not be necessary)

Priority: Critical for launch.

Task: Peer management with shard as a dimension

If we assume that peer discovery takes care of filtering peers by shard, these peers must now be managed in a way that makes sense in a dynamic auto-sharded environment. Some requirements/ideas:

• peer store must preferably try to keep at least a target n peers for each subscribed shard (note that dynamically subscribing/unsubscribing from shards could complicate this)
• peer manager must attempt to maintain a healthy relay connectivity for each subscribed shard
• a mechanism to perform ad-hoc discovery (or another solution) to cater for when a node subscribes to a shard for which there are no tracked peers

Owners:

• Overall: @alrevuelta
• Implementation:
  • nwaku: @alrevuelta
  • go-waku: @chaitanyaprem
  • js-waku: ?? (may not be necessary)

Priority: Critical for launch

2.1: Production testing of existing protocols

Task: Migrate deployments to PostgreSQL

Ensure that new and existing Waku fleets use PostgreSQL by default.

Owner: @Ivansete-status
Priority: Critical for launch

Task: Store/archive schema optimisations

Optimising the DB schema in general for faster queries. Task also includes guidelines for optimising PostgreSQL configuration for performance, if there's anything to be done (e.g. suggestions re replication, etc.)

Owner: @Ivansete-status
Priority: Critical for launch

Task: Assist in dogfooding filter/lightpush/store

Status and other applications are starting to use the latest version of these protocols. It is likely that specific support queries or protocol improvement requests arise from such dogfooding efforts.

Owner: ???
Priority: Critical for launch

Task: SDK for using filter/lightpush

Filter relies in many ways on the same building blocks as relay for its reliability, but in a modular, "pick your own tradeoffs" way:

• redundancy (for relay in full message connections, for filter in subscriptions)
• randomness (selecting random peers for connection/subscription, preferably with some peer cycling)
• periodically checking that you received all messages against a cache (this doesn't really exist yet for filter, but you could imagine using occasional store queries to achieve something similar)

As such it will be helpful to provide a configurable "reliability" SDK on top of filter for projects without the capacity to build these features from the ground up with filter.

Owner: @danisharora099
Priority: not critical for launch

2.2: Sharded capability discovery for light protocols

Task: Service peer selection on specific shards

Currently a service peer (e.g. a store node) is either provided by the application or it expects the peer manager to suggest a suitable service peer (selectPeer()). This task focuses on the latter: peer manager should provide ability to find service peers for a specific shard, based on the content topic that the application is interested in (e.g. an API call to selectPeer(Protocol, ContentTopic)), or kick off an ad-hoc discovery process until a suitable service peer is found. Client APIs (for filter, lightpush, peer-exchange) should automatically make use of this mechanism if the application does not explicitly set the desired service peer.

Owners:

• Overall: @alrevuelta
• Implementations:
  • nwaku: @alrevuelta
  • go-waku: @chaitanyaprem
  • js-waku: ??

Priority: critical for launch

2.3: Basic distributed Store services

Task: Distributed store service roadmap

Note: This item is underdefined as its completion leads to the definition of many subtasks and a roadmap for the Store protocol

This tracks the work to specify/define the roadmap for distributed store services. This includes:

• the ability to discover Store nodes that provide store services for specific content topics and time ranges and for service nodes to advertise their store services as such
• allow Store service nodes to only store messages for specific content topics/applications.
• store sync mechanism based on message IDs

Owner: @jm-clius
Priority: not critical for launch

3.1: DoS requirements and design

Task: RLN benchmark simulations

Note: This work has already started.

Benchmarking RLN in a production environment by incorporating it into local simulations.

Owners: @alrevuelta / @rymnc
Priority: critical for launch

3.2: Basic DoS protection in production

Task: RLN validation in production

Once we have enough confidence in RLN performance after benchmarking, RLN validation should be enabled by default for relay nodes and deployed to relevant fleets (i.e. fleets that serve RLN-protected shards). For example, once autosharding dogfooding has started, RLN relay could be enabled in the same fleets allowing RLN dogfooding to start as soon as the first members start publishing. Membership contract could at this stage still be deployed only to a testnet. Membership mechanisms are tracked as separate tasks. This task is dependent on a suitable membership contract being deployed and configured on validators.

Owner: @rymnc
Priority: Critical for launch

Task: RLN key mechanism and proofs for all publishers

Ensuring that on all Waku clients publishers can:

• manage RLN membership(s) and keys
• generate and attach RLN proofs when using any publishing API calls (lightpush, relay, etc.)

Owner: @rymnc (but delegate implementation ownership for different Waku clients)
Priority: Critical for launch

Task: Membership for all internal CCs

To kickstart dogfooding, a membership mechanism mostly focused on getting internal CCs to start using RLN. This could e.g. provide instructions to internal CCs on how to generate, configure and keep a suitable key for RLN, collect public key material for eligible CCs (and other parties) via a Typeform, register a membership on their behalf in a membership contract and ensure that deployed nodes are aware of this contract. At this stage the membership contract can still be deployed on a testnet, although we may want to migrate these initial members to a "final" mainnet contract once stable.

Owner: @rymnc
Priority: Critical for launch

3.4: Production and memberships on mainnet

Open membership mechanism

Mainnet contract (and instructions/guide) where anyone willing to pay the registration transaction fee can register a new membership, with membership limit set upfront. At this stage deployed RLN validators should build memberships off mainnet.

Owner: @rymnc
Priority: Critical for launch

Task: Dogfood RLN in production

Once the correct contracts are in place, RLN validation is enabled by default on all nodes and the necessary features implemented for publishers to generate RLN proofs, end-to-end dogfooding can commence on the Waku Network.

Owner: @rymnc
Priority: Critical for launch

Final task: Launch and dogfood Waku Network

Although technically tracked under the general track (1), I've listed this as the last task. Once all tasks labelled as critical for launch has been completed, launch and dogfood the Waku Network MVP as set out in #1 by the end of 2023.

[richard-ramos]

For go-waku, I have the following observations:

Autosharding this work has not been started in go-waku, but looking at the implementation on nwaku, i believe we should reach feature parity quickly! I'll extract the list of task tomorrow at early morning my time so a milestone can be defined in go-waku for it.

Task: Validation mechanism to limit "free traffic" on the network There's an open PR in waku-org/go-waku#616 with this functionality. It needs to be modified to comply with the design mentioned here. I can be assigned as owner for that task.

Task: Failsafe mechanism (guide) for BW limiting: I understand that the work done here for nwaku can (probably) be reused with go-waku as well, since it seems to rely only on documentation and third party tools

[chaitanyaprem]

Few observations/suggestions:

• High level Suggestion: It would be good if we can indicate what is the expectation/priorities from each Waku implementation for the Waku Network MVP. This would help us also think specifically what else maybe required to be ready for the network launch. My assumption/understanding is nwaku would be used as service-node(run only by node operators), go-waku and js-waku would be used by developers/applications to build light/full node clients to interact with service nodes.

• As the network goes live with Auto-Sharding and gen0 shards, is there some metric users/node-operators can refer to get an idea of the bandwidth usage for each shard? This would help them decide which shards to support/use. Or will this also be defined as part of the Network spec itself?

• This tracks the work necessary in each client to provide API(s) to applications using req-resp protocols (store, lightpush, filter, etc.) with optional pubsub topic arguments. Shouldn't the API take an optional content topic or am i missing something? The idea with Autosharding is that application/users need not worry about pubsub topic and only care/exposed about content-topic right.

• Task: Peer management with shard as a dimension: You can assign this to me.

• Task: Service peer selection on specific shards : You can assign this to me.

• I think we should have some sort of a network view/health view(
  maybe a separate milestone) which provides some information regarding health of the shards and network. Something like this https://beaconcha.in/

• how many relay peers are available, service peers per shard.
• Current bandwidth utilization of each shard
• how many nodes for each implementation are online.

• Task: Distributed store service roadmap - Can assist you in case you need help

[jm-clius]

Thanks for the comments so far! Answering one by one:

@richard-ramos

Autosharding this work has not been started in go-waku, but looking at the implementation on nwaku, i believe we should reach feature parity quickly!

May be worth syncing with @SionoiS here on timeline, as there're still some architectural discussions happening during PRs (in other words, nwaku's current changes may be provisional in some aspects).

Validation mechanism to limit "free traffic" on the network There's an open PR

Great! Have added you as owner for go-waku.

Failsafe mechanism (guide) for BW limiting: I understand that the work done here for nwaku...

Yes, I think these will be general guidelines that apply to all clients. Have updated ownership to reflect.

@chaitanyaprem

Good comments re contextualising role of each client. I think this also depends on the client team themselves, but generally nwaku/go-waku aim to have full range of capabilities while js-waku focuses on client-side protocols. nwaku is indeed the one we direct operators to run, but if e.g. Status integrates with the Waku Network, similar capabilities would be required in go-waku (we want Desktop nodes to be runnable as a store/filter/lightpush service node).

is there some metric users/node-operators can refer to get an idea of the bandwidth usage for each shard

Ensuring we have proper metrics is indeed implicit especially under the 1.3 tasks, but good to have this mentioned! Existing metrics might already be sufficient. Note that the MVP for the Waku Network currently assume that nodes simply subscribe to the shards belonging to subscribed applications, with more sophisticated auto subscribe/unsubscribe roadmapped for the future. For operator nodes (those not running a specific application), the metrics will be helpful.

Shouldn't the API take an optional content topic

Ah, I see why this may be confusing. In short - the API calls generally takes a mandatory content topic and mandatory pubsub topic. While content topic must remain mandatory, the APIs should be modified to make it optional for applications to provide a specific pubsub topic (i.e. it can be inferred from the provided content topics).

I think we should have some sort of a network view/health view

Great idea! I think the existing Waku Network Monitor will already cover much of the required functionality here, but, indeed, we have to make sure that we have all the metrics we need and an accessible dashboard for it.

Thanks for volunteering ownership elsewhere, will add.

[SionoiS]

I added 1.4 as a milestone in Nwaku repo

[chair28980]

Tasks that do not have specifically assigned owners:

1.2 Autosharding for autoscaling

• Autosharding API for req-resp protocols
  • js-waku: ??
• Autosharding API for (relay) subscriptions
  • js-waku: ??
• Autosharding protocol changes for req-resp protocols
  • go-waku: ??
  • js-waku: ??

1.3 Node bandwidth management mechanism

• Validation mechanism to limit "free traffic" on the network
  • js-waku: ??

1.4 Sharded peer management and discovery

• Peer discovery with dynamic shards as dimension
  • go-waku: ??
  • js-waku: ??
• Peer management with shard as a dimension
  • js-waku: ??

2.1 Production testing of existing protocols

• Assist in dogfooding filter/lightpush/store
  • Owner: ???

2.2 Sharded capability discovery for light protocols

• Service peer selection on specific shards
  • js-waku: ??

[chaitanyaprem]

• For go-waku, me and @richard-ramos will syncup on Monday and split the tasks amongst ourselves.
• Peer discovery with dynamic shards as dimension - Can be assigned to me. Looks like i missed it in my earlier comment.
• Reg DoS protection: I was discussing with @rymnc the other day and i think we need to include some DoS protection apart from RLN. As I understand RLN would take care of spam in the network, but would not actually prevent a node from detting Dos'ed (which could happen with invalid messages). We cannot rely on gossipsub scoring to prevent this since a node can keep changing its peerID and keep Dos'ing any node in the network. Until we have a better way to deal with DoS, should we have some rudimentary IP based blacklist maintained at node level(in case a node sends more than x invalid messages in a time-period) as a start? This isn't enough or accurate, but would be a good way to limit nodes from DOS'ng(as at-least it would be hard to keep getting new IP's as frequently as a new peerID). @jm-clius , @alrevuelta thoughts.

[richard-ramos]

More observations product of @chaitanyaprem and I's weekly sync call:

• While a third party node bandwidth management mechanism could work for go-waku when run as a service node, go-waku is used as a library in status-desktop, so we need to investigate whether it is possible to either modify go-libp2p to add bandwidth restrictions, or ship this third party tool as part of the status-desktop binary for cases when status-desktop is run as a full node. (Ideally a status desktop user should be able to setup the bandwidth restrictions via UI)
• Some of this functionality has been already implemented in status-go and would be interesting to extract it to become part of go-waku, altho I imagine this does not have any impact in the roadmap itself:

Task: SDK for using filter/lightpush: randomness (selecting random peers for connection/subscription, preferably with some peer cycling), periodically checking that you received all messages against a cache (this doesn't really exist yet for filter, but you could imagine using occasional store queries to achieve something similar)

• go-waku does support PostgreSQL too and would probably benefit from these optimizations:

Task: Store/archive schema optimisations: Optimising the DB schema in general for faster queries. Task also includes guidelines for optimising PostgreSQL configuration for performance, if there's anything to be done (e.g. suggestions re replication, etc.)

[fryorcraken]

Task: Failsafe mechanism (guide) for BW limiting
Task: Dynamic subscribe/unsubscribe mechanism (or similar)

Would be good to note this is important for Status

Regarding any relay specific work in js-waku: This should be done in js-waku but is not critical for launch. Cc @waku-org/js-waku-developers

Regarding any "service node" work for js-waku: not needed at this point in time (e..g ENR update)

Regarding nwaku vs js-waku vs go-waku. Let's align on the priorities and what is critical for launch:

• nwaku as a service node, meaning relay and server side of req/resp protocol, and operator tools
• go-waku as a relay and light client node, meaning relay and client side of req/rep protocols
• js-waku as a light client node, meaning client side of req/resp protocols.

This does not mean that nwaku should not implement client side of req/resp protocols or go-waku should not implement postgresql.

What it does mean is that nwaku should prioritize operator tools (e..g bw management) over redundancy capabilty for filter as client.
Or that go-waku should prioritize RLN free traffic over PostgreSQL implementation.

Let's focus in what is critical for Waku Network Gen 0.

Do note:

• Distributed store work will enable Status Desktop to serve store, meaning at this point the PostgreSQL optimisation in go-waku will become important
• As part of making Waku available to more languages, we will aim to provide wrappers for nwaku, meaning client side of req/resp protocol will become important.

Let me know if disagree/not clear.

[fryorcraken]

• go-waku as a relay and light client node, meaning relay and client side of req/rep protocols

Edit: Need to clarify rust-bindings usage from TheGraphcast as I believe they use it as a service node too, if so, we should include go-waku as service node for bindings in scope.

[fryorcraken]

Task: SDK for using filter/lightpush

I would suggest we do this for go-waku and rust bindings too.

cc @waku-org/go-waku-developers

[chaitanyaprem]

Do we need to include REST API also as an item to be tracked as part of this?

[fryorcraken]

• go-waku as a relay and light client node, meaning relay and client side of req/rep protocols

Edit: Need to clarify rust-bindings usage from TheGraphcast as I believe they use it as a service node too, if so, we should include go-waku as service node for bindings in scope.

Currently TheGraph only use rust bindings as a "client" or relay node and do not provide filter/lp service.

[fryorcraken]

Do we need to include REST API also as an item to be tracked as part of this?

Yes it's a good point, I think we have think about the REST API needs to evolved based on the changes here. cc @jm-clius
Also from the convo here: waku-org/bounties#9 there may be opportunities to enhance the API too for more flexible usage of RLN for example.

[jm-clius]

Do we need to include REST API also as an item to be tracked as part of this?

Indeed. This task breakdown tries to answer "what needs to be done for the network to work?". Within each client there are some implied tasks that I did not necessarily include, but which could be tracked. For example, "Autosharding API for (relay) subscriptions" implies that the API(s) within each client should be extended, depending on which APIs in those clients are used by applications. In nwaku's case this would include the REST API.

[chaitanyaprem]

Do we need to include REST API also as an item to be tracked as part of this?

Indeed. This task breakdown tries to answer "what needs to be done for the network to work?". Within each client there are some implied tasks that I did not necessarily include, but which could be tracked. For example, "Autosharding API for (relay) subscriptions" implies that the API(s) within each client should be extended, depending on which APIs in those clients are used by applications. In nwaku's case this would include the REST API.

OK, maybe i should have clarified. Is REST API a priority for go-waku for this launch? It may not be, considering go-waku serviceNode is not a priority for this launch.

[jm-clius]

Is REST API a priority for go-waku for this launch?

Afaict, no, it's not a requirement for the launch.