Waku 0 spec improvements

[decanus]

• Add handshake details
• Outline difference between bridging and data format
• Think about how to maintain forwards capability for waku/v0 (Waku 0: Document forward compatibility #41)
• elaborate on security considerations (Waku 0: Include privacy, scalability and DDoS considerations #39)
• Light node security considerations
• Implementation notes and have something similar but lightweight to https://tools.ietf.org/html/rfc8446#appendix-C (ping client implementers)
• Implementation Matrix
• Document further differences with Whisper v6 (Kim?)
• Document recommendations for mobile nodes node
• Describe rate limit (see recently merged PR in status/specs) Waku 0: Describe existing rate limiting #40
• Port handshake paragraph from https://github.com/status-im/specs/blob/master/status-whisper-usage-spec.md#handshake
• Whisper Envelope data field (Optional) section weird and has partial ABNF

Mailserver

• Clean up vocabulary, is it mailserver and mailserver client? mailclient? mailserver node? historynode? etc

ABNF

• Run ABNF validator, ensure it parses (can map to rlp shortcut types like '[' or 'rlp list' etc
• ABNF for whisper envelope

Out of scope for waku v0 (create issue only)

• Created issue: Add waku mode in v1, it isn't in the spec yet Waku v1: Optimize bandwidth usage #49
• Create issue roadmap https://github.com/vacp2p/pm/issues/5

[decanus]

Outline difference between bridging and data format

@oskarth I think you created this todo, what does this mean exactly?

[oskarth]

Outline difference between bridging and data format

There's a difference between being compatibility protocols and compatibility at data layer. I.e. Waku/0 is a different subprotocol, so it isn't compatible with Whisper v6, hence bridge. However, its envelopes content are identical/compatible, so naive bridging without knowing content works. This difference should be clear in the spec.

Additionally, for waku/1 waku/2 etc, we might want to do some form of protocol negotiation, so it defaults to the lowest commonly supported protocol.

[decanus]

@kdeme @adambabik it may make sense for you guys to document the Implementation Notes as I have never implemented a waku / whisper node its hard for me to judge.

[oskarth]

Document further differences with Whisper v6

@kdeme any chance you could take a look at this one? Changelog in spec has section "Differences between shh/6 waku/0" and it'd be great if all the major differences were there. E.g. handshake business and whatnot

[oskarth]

@decanus @kdeme what's the state of this issue?

[oskarth]

Rate limit should be added from here too status-im/specs#60

[oskarth]

Suggestion for:

Document recommendations for mobile nodes node

Write use light node for now, then in PR ask Adam and Kim for review to get more potential tricks

[decanus]

@oskarth gonna mark Think about how to maintain forwards capability for waku/v0 (#41) as resolved as there is an open discussion around it.

[decanus]

@oskarth to the point of Port handshake paragraph from, are we happy with the current paragraph in the status message or do you feel like we need to add more detail?

[oskarth]

@oskarth to the point of Port handshake paragraph from, are we happy with the current paragraph in the status message or do you feel like we need to add more detail?

https://github.com/status-im/specs/blob/master/status-whisper-usage-spec.md#handshake this seems fine to me, I believe our ABNF etc doesn't reflect this state (after rate limiting discussion)

https://specs.vac.dev/waku.html handshake section doesn't mention optional stuff, and grammar is wrong

[decanus]

Document further differences with Whisper v6 (Kim?)

@kdeme is this done for you? if so check the box please.

[decanus]

Implementation notes and have something similar but lightweight to https://tools.ietf.org/html/rfc8446#appendix-C (ping client implementers)

also @kdeme this would be useful for you to comment on, do you have any implementation notes?

[decanus]

@oskarth I think we can consider this done, the ABNF stuff is in a different issue & we may be too early for recommendations and implementation notes. Not sure if @kdeme has thought about those 2.

[oskarth]

Sounds good to me, lets close it