search

status-im / specs

Specifications for Status clients.
https://specs.status.im/
MIT License
14 stars 14 forks source link

Early draft: Waku mode spec #54

Closed oskarth closed 4 years ago

oskarth commented 4 years ago

See https://github.com/status-im/specs/issues/53 and discuss post

oskarth commented 4 years ago

As @yenda mentioned on discuss, it would be important to have secure communications between the waku-chan and waku-san, so that meta-data does not leak any further than the waku-san.

Considering the flaws of devp2p, perhaps this should not be allowed as a lower transport in this scenario? Or at least it should be clear of the possible consequences.

Long term we want to move to libp2p. For the initial PoC, I'd suggest we stay with DevP2P and note possible consequences. In terms of threat matrix it is fairly low in terms of severity and probability, IMO.

@adambabik also suggested HTTPS. I'd like to see some very strong arguments for us to move to it, as it is not really on the path we want to take long term. What would it give us? What are the trade offs? How much time would it take to implement? How would we switch from it to devp2p/libp2p in adaptive node (note waka mode can be reset / fine-tuned)?

oskarth commented 4 years ago

Maybe it could be as simple as adding a field to the existing Whisper handshake, to identify as Waku-chan or Waku-san.

True, how would this work if Whisper API were to change in the future (unlikely but eh)? I.e. can we ensure we don't take up a spot that might be used by other nodes?

Not too familiar with EIP-8 requests but sounds possibly useful.

Is this something you'd like to play around with further @kdeme to help tighten up the spec / get poc?

cammellos commented 4 years ago

@adambabik also suggested HTTPS. I'd like to see some very strong arguments for us to move to it, as it is not really on the path we want to take long term. What would it give us?

I think we should simplify the current way of doing this, and have a simple request-response sync pattern, regarding HTTPS , sounds like a safe option, but don't have a strong opinion on the matter.

adambabik commented 4 years ago

@adambabik also suggested HTTPS. I'd like to see some very strong arguments for us to move to it, as it is not really on the path we want to take long term. What would it give us? What are the trade offs? How much time would it take to implement? How would we switch from it to devp2p/libp2p in adaptive node (note waka mode can be reset / fine-tuned)?

I have a few :)

  1. Managing connections in p2p systems (including peers selection, reconnects) is much more problematic for client and server nodes compared to HTTPS or WebSockets. devp2p abstracts it to some degree and we have experience but still.
  2. HTTPS traffic is easy to load balance so the client does not need to implement the whole logic which in p2p systems is necessary: peers discovery protocol, peers pool, careful management of a number of connected peers to reduce traffic etc. Drawback is that HTTPS and load balancing is more centralized.
  3. I guess Waku node would require many new APIs so it does not matter which way we will go because in both the new methods must be implemented. Having said that using HTTPS requires to copy encryption/decryption and validation logic for messages from Whisper. Using devp2p we probably could stay with large portion of the current Whisper implementation.
  4. With HTTPS there is additional effort to bridge it with devp2p on Waku nodes.

To sump up, HTTPS is an easier communication protocol to work with from the client perspective. It allows us to scale Waku nodes transparently. It also allows more type of clients like pure browser one and should be more reliable in terms of faster reconnects, work better in the restricted environments like airport wifi etc. Cons, it likely requires a bit more work (but it's an opportunity to do it better :)). It also opens this "convenient mode" which once is implemented will be difficult to get rid of, although, from less aware clients perspective, it does not matter because they will have better experience using the app. Switching between these two modes would not be a bad idea.

oskarth commented 4 years ago

Draft PR out of date, see https://github.com/vacp2p/specs/pull/61/files and https://forum.vac.dev/t/waku-project-and-progress/24 for latest