Waku Socket (better name pending)

[D4nte]

From the p2p WebRTC exploration, a requirement has emerged to design a protocol that enables two peers to communicate over Waku using their peer id as identifier.

In a first phase, the protocol does not need to be encrypted (signal server sees all content in clear). However, it may be interested to add a layer of encryption using https://rfc.vac.dev/spec/35/ at some point.

The usage of peer ids as identifier is to enable this protocol to be used as libp2p transport. Which in turns, enables it to be used for WebRTC handshakes.

Note that the usage of peer id is likely to leak out privacy information, enabling anyone observing the network to know who is doing a webrtc handshake with whom.

As we get a first "unsecure" PoC working, we can then iterate and add needed privacy features.

Notes

In terms of technical design, it would make sense to implement an API similar to https://socket.io/ with emit/on/once:

socket.on(event: string, listener: (data: any) => void)

Which means that for each message we have:

• An event string: Tag that describe the event
• A data payload: The type would depend on the event.

socket.io provides a very advanced typing system. We do need to go down this path at first.

Regarding libp2p transport, see the considerations outlined in #20 (comment) especially around multiaddr.

DoD

• A PoC that enables two parties to exchange payload with each other, only knowing each other peer id.
• Implement a libp2p transport using this PoC

[fryorcraken]

Using noise-session directly might be useful here.

[fryorcraken]

https://discord.com/channels/864066763682218004/1019621534769352904/1019871950132219964

[fryorcraken]

May be fixed with waku-org/examples.waku.org#177

[fryorcraken]

The initial use case stemed from Web RTC which is now blocked on libp2p improvement. Ice boxing this.

[fryorcraken]

WebRTC specific work is tracked in #1181

Regarding this issue, the essence of it is encompassed in:

A PoC that enables two parties to exchange payload with each other, only knowing each other peer id.

Enable two parties that know something of each other (ie, a public key) to communicate in an e2ee manner to each other but using something better than ECIES.

How is noise better than ECIES would be good to define so the added value is clear.

Do note similar question asked here: #1181 (comment) pending input.