mediate object methods in wallet (simple data-only args)

Describe the bug

In the demo we just did (#3869 ) most of the UI limitations were due to time constraints, but one that I don’t know how to address even if I had lots of time is: if we sent invitations using wallet deposit facet, how would a voting dApp get access to voting rights, which currently come via zoe getOfferResults?

Additional context

@dtribble seemed to suggest that this is a solved problem, but I haven’t looked into the details…

For apps like the treasury with nested offers, the offer result is a particular structure that the wallet recognizes so that it can provide sub invites

… so to be conservative, I’m raising this issue.

cc @rowgraus @katelynsills @Chris-Hibbert @michaelfig @samsiegart

[dckc]

Thanks for taking the time to spell out the argument, @katelynsills . I’m sorry to make you take the time for that… I have some “trial by combat” habits that I have been trying to break for some time, but they still come out now and again.

[katelynsills]

Meanwhile, @katelynsills , when you say we know we need to build this out in the wallet, I don’t quite understand… As far as I know, using offers / payments for voting could work fine. I don’t plan to do any work in that direction, but as far as I know, it isn’t ruled out as a possible design.

Sure, I can explain. We need our wallet UI to support users calling methods on object capabilities because that is how we have chosen as a company to represent access control. By contrast, Ethereum uses addresses and the addresses’ ownership of tokens for access control. The only reason we have a different access control story because we allow access through holding an object and calling methods on it. If we didn’t allow users to hold object capabilities, we would be the same as Ethereum and have no access control differentiation. So not supporting object capabilities in the wallet would be throwing away a huge part of who we are as a company, and what we’ve been working towards.

And, because we’ve explicitly chosen the object capability approach, our contracts use object capabilities for access control. For instance, when a user opens a vault in the Treasury, they receive an object that has methods for adding collateral, increasing the loan, and closing the loan entirely. Only the holder of this object can take these actions.

The wallet holds all of the user’s objects, and needs to correctly handle valuable object capabilities like the vault. But, there’s a problem, which is that the wallet doesn’t know what vaults are, or how to represent a vault object to a user. This is where dapps shine: they know the specifics of contracts and know the business meaning of particular objects. However, dapps are not trusted by the user, and should not be. Dapps should never have direct access to the vault object, because then they would be able to close the loan and take the collateral for themselves, stealing assets from the user for a hefty profit.

To put it simply: dapps have all of the domain specific knowledge, but none of the authority, and wallets have all of the authority and none of the domain specific knowledge.

The solution we came up with is that the dapp can tell the wallet what to do with the vault based on the user’s actions in the dapp UI, and the wallet can choose to show this request to the user for approval, or otherwise have some logic for doing the action or not. To accomplish this, the wallet gives the dapp a proxy-like object so that the dapp has the experience of calling methods on the object capability, but the wallet has complete control over whether the calls go through. This shouldn’t be too hard, especially since we know we need to rewrite the wallet backend entirely anyways for it to be auditable.

@dckc, to your question of what has been ruled out, you should consider the idea of eliminating the use of object capabilities in contracts and replacing them with tokens ruled out, by me. As engineering lead on Zoe, I would not support any restrictions on the design of Zoe or Zoe contracts that eliminate the use of object capabilities by users. We need our wallet to support object capabilities, because that’s our product story on access control.