Browser based Agoric wallet using SwingSet

[rowgraus]

Goal:
Allow users and wallet providers to run the Agoric wallet without needing a separate ag-solo process.

Notes on approach:

Generalising Swingset controller support so that it can run on the browser (or in other non-Node.js environments) is the best way forward, to maximally leverage our existing code.

• inner half of controller.js, which is pure code that only uses capabilities from the outer half
• outer half of controller.js in SwingSet is the default Node.js implementation
• new @agoric/web-solo
  • implements an experimental outer half of controller.js using Web tech
  • uses TrapCaps for async host, synchronous guest relationships #3171 syncable captp to provide any needed sync APIs
  • "science project" to do sync calls from the controller into the main thread (run controller in worker with its own SharedArrayBuffer, Atomics)
  • run a yarn build to create a tree of files representing generic kernel state and bundle/index page
  • serves build artifacts from a static web server, with the headers needed to enable cross-thread SAB/Atomics
  • static state prepopulates IndexDB
  • any runtime key material is just HD from mnemonic
  • CosmJS for chain interaction

[zarutian]

hmm... at first glance it looks like purely browser based would require that the wallet bridge iframe whatchacallit handle captp messages instead of going through a websocket. But I have to investigate websockets and service workers.

[michaelfig]

@warner here is the issue you're looking for.

[michaelfig]

hmm... at first glance it looks like purely browser based would require that the wallet bridge iframe whatchacallit handle captp messages instead of going through a websocket.

My plan for this is to use Wallet Connect #2962, for which the dapp can name a WS forwarding address+shared secret and then that string is communicated out-of-band to the wallet. Then both sides connect to the WS server, negotiate a shared channel, and use a shared secret for encryption so the WS server doesn't see the transactions.

But I have to investigate websockets and service workers.

That's a difficult issue. Service workers + websocket is even less portable.

[zarutian]

I have investigated the service worker and websocket route. I thought one might be able to intercept websocket connection requests with service worker like http requests are. Turns out it is not possible, so that is out for purely browser based wallets.

This Wallet Connect looks promising but it does not sit right with me that dapp<->wallet traffic would have to go out into the Internet and back.
Mostly because that eats up mobile network bandwidth. Hmm... might it be possible for Wallet Connect to use similiar trick Q-Connection did with 'transports' and, for browser only dapp and wallet combos, have a hidden iframe that gets postMessage'd and does postMessage as the 'transport'. Unbeknownst to the dapp client of the WalletConnect client library?
That way mostly no dapp<->wallet traffic leaves the mobile device.