Generalize session management by porting WalletConnect to Waku

[petty]

Thanks for sharing your idea! Please use this template to keep things organized

Idea name: Generalize session management by porting WalletConnect to Waku

Description: Ok, this is a bit of doozy, and goes beyond just the Status application itself, and results in many features.

WalletConnect (WC), in its current form, is a method for dapps being viewed in the browser to connect to a group of wallets for account management and signing. It uses a central bridge server run by WC to establish a session between the dapp and the wallet via websockets. Pedro, WC progenitor, has long had the desire to decentralize this process.

The proposal here is to port his bridge server to Waku, but also to generalize it to handle any session negotiation. This basically allows two parties who “speak waku” to discuss the handshake they’re going to make. Which means they may even take the connection out of band, e.g. video chat via webRTC session (see Dean’s recent post on this).

Having this built-in to Waku allows for some other interesting things:

• creative options for a Status-webview that is run off of the phone’s secure key management, similar to how WhatsApp web works
• Optionality with people using Desktop and how they bring accounts to it
• ETH2 deposit/validator management views?
• Status as infrastructure supporting the ecosystem (potentially without much load if sessions are actually taken out of band)

Just having the ability to connect to any dapp on any browser on Status is a helluva PoC.

Current needed work:

• waku-ts (or similar)
  • to handle browser sessions sending/receiving envelops on some topic via websockets.
  • request a waku_subscribe for topics remotely
  • receive websocket messages on topic
• drafting the generalized session management packet specifics
  • @decanus refers to this as a signaling protocol, I’ll let him differentiate if he is thinking differently than me.

Previous ideation schematic from @pedrouid:

Use case: As a user, I want to leverage the Waku network so that I can not care about the thing used to visit a dapp and initiate sessions with wallet/voice/video securely and in a decentralized manner.

Target user: The Web3 community, Status users wanting modern chat app features.

Why this is important: see description

Any other comments:
Previous conversation in 2018 around this: https://discuss.status.im/t/web3-js-whisperprovider-sign-with-status-everywhere/370

If you think this is a great idea and know how to implement it, consider posting a project proposal on Assemble.

[decanus]

@petty

refers to this as a signaling protocol

So signalling is what it is referred to as in the WebRTC spec. See: What is WebRTC Signaling?

[pedrouid]

Yeah essentially WC was always designed to be used on a pubsub network and you can check this on the Bridge server which essentially mimics this behavior

There are two core parts to the protocol: the secure remote connection between two clients and the session management for JSON-RPC requests

However these two are too intertwined in v1.0 and hard to decouple so this diagram demonstrates how the v2.0 would establish a secure connection first and then initiate N sessions through it

In these session proposal I’ve specced something that would be flexible enough to use different transports and it could potentially be used for signaling to initiate WebRTC sessions

Also that diagram has some issues which me and Sebastian (who will be developing v2.0 with me) have ironed out and basically there would be a key exchange prior to connection establishment and then consequent sessions will have a proposal prior to session agreement

I will share a more detailed diagram soon