Separate Wallet API for POLA

[michaelfig]

What is the Problem Being Solved?

The home.wallet API surface has evolved organically, and now we are at a place where we need to take steps to carefully (but still compatibly) redesign the API, since it currently serves multiple clients: the REPL, deploy scripts, wallet frontend, dapp UIs, and maybe eventually dapp API servers.

Description of the Design

In #2032 we move most of the existing Wallet API off of home.wallet and into sub-APIs, categorizing the facets that are relied upon as:

• WalletUser - full access to all of the wallet's APIs, whether via the ag-solo REPL or a trusted deploy.js script
• WalletDataBridge - the data-only (no CapTP) wrapper for the WalletBridge that is currently available via the iframe/WebSocket path
• WalletBridge - the ideal (ocap-only) facet available to a dapp
• WalletAdmin - the facet needed by dapp-svelte-wallet (over CapTP)

The goal of this phase is to separate these concerns so that they can evolve separately while maintaining compatibility with existing WalletUser and WalletDataBridge clients. WalletAdmin is created to mark the portions of the API that we are not yet publically committing to, as it is driven by the needs of dapp-svelte-wallet and exposing portions of it on WalletUser will need to be designed carefully.

The goal is to enable the independent evolution of (please expand this list/attach issues as desired):

• petname management methods exposed on WalletUser
• direct clients of the WalletBridge (such as dapp API servers via the chain using rendezvous Rendezvous service #1861)
• improved WalletAdmin APIs and simpler wallet UI interactions
• further changes without breaking backward compatibility

Security Considerations

There should be no impact of the above refactoring upon security. It is noted, however, that most deployment scripts should not be given full access to REPL objects such as home.wallet, rather they should request only the powers they require.

Test Plan

Each of our official dapps should be deployed and tested against the wallet to ensure compatibility with the new factoring.

[michaelfig]

Tagging @dtribble, @katelynsills.

[rowgraus]

To bring up to date and epicized

[dckc]

@michaelfig is this still relevant to life as we know it, given that #1074 is done? If so, please refine the title to be more clear about how / why we should redesign the API.

[michaelfig]

@michaelfig is this still relevant to life as we know it, given that #1074 is done? If so, please refine the title to be more clear about how / why we should redesign the API.

This is in progress, with PRs such as #4338 . I will close this issue when we're done with that process.

[dckc]

I'd still like a more clear title / description. As it is, any change to the API might constitute a redesign sufficient to close the ticket. The description says that the design evolved somewhat organically, but it doesn't say any particular ways that the design is insufficient.

[michaelfig]

As it is, any change to the API might constitute a redesign sufficient to close the ticket.

That was the intent of this ticket: to have any redesign. We are settling on one that supports the on-chain wallet.