oskarth

Seems reasonable to me. @jm-clius @staheri14?

I'm not sure the "core" distinction is great as it stands. For now Waku v2 is "core" but the way it is defined now is a bit arbitrary. MVDS is...

It seems like we primarily want to distinguish "waku applications" here. What about using tags instead? And adding tags: - Waku applications - Waku core protocols

Yeah basically, I think it'd work as less of a straitjacket. Basically a spec can then have 0, 1 or many tags. For now the only need we have identified...

> A straightforward way to point dapp developer to existing application protocols has been implemented in the RFC repo. If this is the acceptance criteria, I think it makes sense...

Would you mind having a look at this and update specs accordingly @staheri14? Should be a simple fix

Let's not mix Waku v1 and Waku v2 terminology. Waku v1 shouldn't have any references to Waku v2, other than perhaps saying "here's the new version". Lightpush, filter protocol (not...

Migrating from discussions (https://github.com/vacp2p/rfc/discussions/427 will be dead soon). Assuming this https://github.com/vacp2p/rfc/discussions/427#discussioncomment-1010374 clears up the other issue. If not, let's open a separate issue for that problem. For now I'd probably...

NAT is addressed here https://github.com/status-im/nim-waku/blob/master/waku/v2/node/config.nim#L44-L47 and follows same pattern as Nimbus is doing, which is working for Eth2.

Thanks @staheri14 and @John-44 for the discussion! Some partial answers to things mentioned: > Yes they can, but they must have initially started as a full store protocol, I think...