The current limits of the ocap fabric

[michaelfig]

What is the Problem Being Solved?

The composability of Agoric is determined by extending the ocap model to different software agents that come in contact with the current limits of that fabric. This issue describes coherent directions in which we could grow the fabric, with the intent of starting a conversation about our priorities as well as low-hanging fruit.

Description of the Design

We partition our software into three basic categories: persistent replicated (PR), persistent solo (PS), and ephemeral (E).

TODO: Add @erights diagram.

The following is a list of the software agents we've implemented thus far. Below each item is a sublist of connections to other agents, where a checkmark indicates that this connection can convey ocaps.

• Agoric Chain (PR, cosmic-swingset/ag-chain-cosmos)
  • [x] ag-solo - VatTP over cosmic-swingset tx
  • [x] other chains - VatTP over IBC
• ag-solo (PS, cosmic-swingset/lib/ag-solo) whether as a "user's VM" or a "dapp API server"
  • [x] Agoric chain - VatTP over cosmic-swingset tx
  • [x] web UI - CapTP built into endpoint handlers
  • [ ] legacy web UIs - custom POST/WebSocket RPC
  • [ ] other ag-solos - custom proxy via dapp UI
• Wallet web UI (E, dapp-svelte-wallet/ui)
  • [ ] user interface - custom UI does not expose ocaps
  • [x] Wallet backend - CapTP over WebSocket
• REPL web UI (E, ag-solo/html)
  • [x] user interface - the user can interact with ocaps
  • [ ] REPL backend - POST/WebSocket custom protocol
• Deployment scripts (E, agoric-cli/lib/deploy.js)
  • [x] ag-solo - CapTP over WebSocket
• legacy dapp UI (E, dapp-*/ui)
  • [ ] dapp API server - custom POST/WebSocket RPC
  • [ ] user's wallet - custom iframe<->WebSocket RPC
• SwingSet runner (PS, swingset-runner)
  • [x] inter-vat connections
• Pledger (PS, Pledger/packages/plugin-agoric)
  • [x] browser UI - CapTP to renderer
  • [x] renderer process - CapTP to UI and backend
  • [x] backend process - CapTP to renderer

Security Considerations

Connections that can convey ocaps need to use their own access control to decide which bootstrap objects are accessible. Once the initial references are exchanged, ocap discipline can be used to partition the resulting API surfaces.

Test Plan

TBD

[michaelfig]

@rowgraus you may want to have a look at this.

[zarutian]

One question I have will the dapp web ui through wallet bridge iframe through websocket through wallet ag-solo through to Agoric captp comm path will be supported?

That way a dapp developer does not need to host an Internet reachable ag-solo. (Heck, could even just do a small dapp via ittybitty sites or data uri hosted in a string variable inside the smart contract instance itself)

The bootstrap object given to the dapp ui would have getZoeService() and getBoard() in addition the usual for wallet bridge dapp access. Those two would give access to Zoe and the board on the Agoric chain.

[michaelfig]

The bootstrap object given to the dapp ui would have getZoeService() and getBoard() in addition the usual for wallet bridge dapp access.

Yes, that's an interesting mechanism for dapps that only use public facets. I will bring it up again as a simplification that would likely often be useful.

Thanks for mentioning this!

[zarutian]

The bootstrap object given to the dapp ui would have getZoeService() and getBoard() in addition the usual for wallet bridge dapp access.

Yes, that's an interesting mechanism for dapps that only use public facets. I will bring it up again as a simplification that would likely often be useful.

Thanks for mentioning this!

Such a dapp can compose an offer that the wallet can then execute. For instance, one can change the card sale dapp to use the smart contracts instance public facet to see which cards are available, use wallet purses info status which cards the wallet owner already owns, etc. Same with the pixel place dapp. I can think of many more examples of dapps that do not need publically reachable api ag-solos yet allow for customized trade.

[michaelfig]

I looked over our main public dapps. The checked ones below could easily have public UIs that are API-less as described by @zarutian in https://github.com/Agoric/agoric-sdk/issues/2050#issuecomment-735468711:

• [x] dapp-autoswap
• [ ] dapp-card-store
• [x] dapp-encouragement
• [ ] dapp-fungible-faucet
• [x] dapp-oracle (for its public UI)
• [ ] dapp-otc
• [x] dapp-pegasus
• [x] dapp-simple-exchange

The unchecked dapps would take a (tiny) little bit of thought to eliminate the API middleman, as their contract currently doesn't expose a useful publicFacet.

[katelynsills]

This overview (https://github.com/Agoric/agoric-sdk/issues/2050#issue-749294787) is fantastic, thanks!

[katelynsills]

I tried to diagram the important aspects that are listed above, mostly for my own edification, but in the case that it might be helpful for someone else (@michaelfig feel free to correct anything that is wrong):

[katelynsills]

Would it be possible to move this discussion (https://github.com/Agoric/agoric-sdk/issues/2050#issuecomment-735871717) to a separate issue? I'd like to go into more depth on the exact definition of API-less (I'm assuming it means that it doesn't require a handler.js, but that it may include an ag-solo occasionally with deploy scripts for instantiation, shutdown, and maintenance. In other words, the UI will not be making calls to any backend, although an ag-solo may be used on the instantiator's behalf.) Once we agree on a definition, I'd like to look at all of our current contracts (not just dapps) with Zoe's design in mind, to see which should be API-less, and which should never be. For instance, the OTC Desk contract doesn't currently have a UI, but the contract is designed specifically such that invitations (free covered call options) are private, not public. This is a feature of the original design by Hasseb, so we shouldn't change that. That shouldn't stop us from pursuing an API-less design for Autoswap, though. Having a list of contracts analyzed in this way would be very helpful, I think.