feat(exo): revocables

[erights]

Background: Exos already have a level of indirection between the exposed method with the protective method guard vs the raw method. In order to enable prototype-based method sharing of the protective methods, they lookup the context from their this, which is the exo object itself. The context is then passed as the this to the raw method. Having paid for this level of indirection, we already use it for many benefits, like enforcing that the exposed methods cannot be applied to unrelated instances.

An additional benefit we can obtain from this indirection is revocation. However, creating a revocable exo is the odd case. We don't want the normal case to pay an undue notational cost to accommodate the odd case, even if that raises the notational cost of the odd case a bit. We do so by allowing an additional getRevoker option, which is called with a revoke function to be called with the exo to be revoked as an argument.

This seems unduly higher order. But the getRevoker option is directly analogous to the executor argument of the promise constructor, which is called with a resolve function to be called with a resolution.

This is motivated by the benefits of direct support for revocation for exos at the liveslots level, which needs a parallel implementation of exactly the same options with the same observable semantics. At the liveslots level, the benefits would be

• A step towards dropping exports of used-up exo objects such as payments, relieving distributed gc pressure.
• A step towards Zoe2 use objects that can be turned (back) into transferable invitations.

Once this support is uniform across heap exos (from this PR) and virtual and durable exos ( Agoric/agoric-sdk#8020 , Agoric/agoric-sdk#8008 ), then perhaps zones can mirror this universal support. Further, zones themselves could conceivably absorb the revocation support, to provide batch revocation according to creating zone.

[michaelfig]

Looking good so far.

[erights]

Closing in favor of #1668

[erights]

Reopening. Having tried to use the API of #1668, I now think this one may be the better approach. But also leaving #1668 open while investigating.

[erights]

@michaelfig @FUDCo @warner , now that Chip is back, we should talk about this. In particular, the major design choice: should the unit of revocation be the facet or the cohort of facets?

[erights]

@FUDCo and I discussed the main controversy, and decided that revoking a facet revokes just the facet, not the cohort. This PR does not yet reflect that decision.

[erights]

@FUDCo and I discussed the main controversy, and decided that revoking a facet revokes just the facet, not the cohort. This PR does not yet reflect that decision.

It does now.

[erights]

Reviewers, ping.

@kriskowal is gearing up to make a new endo release. I'd like to get this in there, because agoric-sdk needs to be able to depend on it in order to proceed with the work there to support the same feature for virtual/durable exos. Thanks.

[michaelfig]

LGTM. Please choose between my two suggestions for more clearly specifying what you mean by object.