feat(exo): internal revocables

[erights]

Alternative to #1666

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.

We do this by having all the context (this) objects for a given class (or classKit) inherit a common revoke(obj) method. Thus, revoke(obj) is available from inside instances of a class (or classKit), but not available outside. However, in the current design, this is a per-class (or classKit) power, not a per-instance power. Any instance of a class (or classKit) can revoke any other that it has a reference to. Revoking any facet of a kit revokes all facets of that kit.

This is motivated by the benefits of direct support for revocation for exos at the liveslots level, which needs a parallel implementation with the same observable semantics. As 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 (a future agoric-sdk PR), then zones can mirror this universal support. Further, zones themselves could conceivably absorb the revocation support, to provide batch revocation according to creating zone.

[erights]

The savings of sharing the inherited revoke method is not worth the complexity it causes. TODO switch to a per-context revoke() closure.

[michaelfig]

The savings of sharing the inherited revoke method is not worth the complexity it causes. TODO switch to a per-context revoke() closure.

I agree. But this PR seems like a step in the right direction. Please @mention me when you are satisfied with a specific implementation, and I'll review it.

[erights]

Remove. No more proto to ignore

[FUDCo]

It feels unintuitive to me that revoking a facet also revokes all the other facets. In particular, naively I would think it would be a plausible use case to have an object with one facet whose very purpose is to be given out (and thus wants to be revokable) while another facet is retained internally for one's own use. I understand this might involve a potentially unreasonable amount of bookkeeping, so rejecting for that reason might be the right choice, but if so this reasoning ought to be explicit. Or is there some different use model in mind here that motivates this design choice?

[erights]

It was the bookkeeping. Suggestions for better bookkeeping for virtual objects?

Btw, I turned this back to draft for several reasons. But one is: I think my mechanism here is only deleting the representative from the cache, but not persistently killing the baseRef. But it needs to persistently kill the baseRef or vref, as well as, ideally, notifying liveslots so liveslots can drop the exports. Suggestions?

[erights]

Reversed decision. Now closing in favor of #1666