Waku v2 adaptive nodes and capabilities

[oskarth]

Update

We decided to do it already anyway, see comment thread below.

Old issue for context

General problem and context

See #87 for general context.

In track 3 (https://vac.dev/waku-v2-plan) there's a subproject re this:

1. Adaptive nodes and capabilities

We want to make the gradation between light nodes, full nodes, storing (partial set of) historical messages, only acting for a specific shard, etc more flexible and explicit. This is required to identify and discover the nodes you want. See #87

Depending on how the other tracks come together, this design should allow for a desktop node to identify as a full relaying node for some some app topic shard, but also express waku topic interest and retrieve historical messages itself.

E.g. Disc v5 can be used to supply node properties through ENR.

Proposed decision

Specifically, I'd like to argue that we can and should defer addressing this until we have gotten basics done in Waku v2 track 1. It is important that we get it right, but we are not quite at the stage where we can discuss about this at the detail required. This requires clarity on how topic/content etc operate.

After we have basically fulfilled track 1 (https://github.com/vacp2p/research/projects/1 and vacp2p/research#40) then it makes sense to take a step back and consider how to best express capabilities in various forms (protocol strings, discovery, as part of negotiaton, etc etc).

This means that we wouldn't create another protocol such as waku/mailserver/1.0.0 or similar for light nodes. That doesn't mean they can't be cut up into different capabilities, just that we are not yet in a position to do so.

Doing this will simplify spec and implementation (e.g. see #163 and #165) and means we'll get to track 2 and track 3 faster.

---

cc @kdeme @decanus if you want to express strong disagreement with this approach.

Misc notes

• ENR record Eth2field
• ENR Disc v5 attribute ( discv5: add FINDNODEATT message ethereum/devp2p#151)

[oskarth]

Based on discussion in waku-org/nwaku#92 (comment) it seems like it'd be better to do this now rather than later.

We have a bit more clarity on topic and content after recent spec editions and simplified Node API.

This means we can do part of this now, while deferring more granular discovery etc until later.

[oskarth]

https://notes.status.im/2jVPeCtHQeeh4P_mfJN3Qg#

[oskarth]

Going to close this for now as it is a bit outdated. We have made some progress on this with protocol split etc.