fix(exo): remove receiveRevoker

[erights]

closes: #XXXX
refs: #1666 Agoric/agoric-sdk#2070 Agoric/agoric-sdk#8020 Agoric/agoric-sdk#8745 Agoric/agoric-sdk#8749

Description

Reverse #1666's addition of receiveRevoker to the meta-operations of exos.

#1666 defined these for all exos and implemented them for heap exos, under the assumption that they would eventually be implemented in agoric-sdk for virtual and durable exos as well. Doing so turned out to be harder than expected Agoric/agoric-sdk#2070 , leading the attempt to do so Agoric/agoric-sdk#8020 to instead resort to a shim emulation that is neither scalable nor durable, and so unfit for production.

The main motivation for revocables is as a lower layer abstraction supporting ownables at a higher layer. But the receiveRevoker approach at a low layer led to the Agoric/agoric-sdk#8517 approach to ownables at a higher layer, which was a failed experiment.

Rather, Agoric/agoric-sdk#8745 tries a caretaker approach to revocables at a low level, leading to a pleasant API for ownables at a high level. @dckc's comment at Agoric/agoric-sdk#8745 (comment) suggested refactoring these to depend on zones rather than baggage. Once done, then the caretaker-like revocables become independent of heap vs virtual vs durable, and could be migrated to endo as an alternate form of revocation. But this will depend on first moving baseZone and store to endo, whose first step is Agoric/agoric-sdk#8749

Originally: This change is flagged as fix(exo)!: because it is a compat break. But we are unaware of any uses in production, so it may be a compat break only in theory.

Update: From reviewer suggestions below, I changed this to fix(exo):.

Note that Agoric/agoric-sdk#8021 is the only other PR I know that depends on receiveRevoker, and it is Draft.

Once receiveRevoker is gone, the other similar meta-operations are

• receiveAmplifier, which is already implemented for heap exos.
• receiveInstanceTester in feat(exo): instance testing #1925 , which defines it and implements it for heap exos.

Unlike receiveRevoker, I expect both of these will be easy to implement in agoric-sdk, although this has not yet been tried.

Security Considerations

Fewer privileged meta operations reduced our attack surface. But since this API was already designed to facilitate auditing, that's a minor worry.

Much more important is that removing this from the exo definition means that we no longer need to implement it for virtual and durable exos, enabling us to avoid or postpone Agoric/agoric-sdk#2070 until we need it for other reasons (like Agoric/agoric-sdk#8021 ). Solving Agoric/agoric-sdk#2070 would have been major surgery on a liveslots, which is a security critical component of our system. Better to postpone that risk if we can.

Scaling Considerations

Solving Agoric/agoric-sdk#2070 , enabling uses like Agoric/agoric-sdk#8021 would be a major help to scalability. Postponing it postpones this scalability benefit. But this PR itself doesn't cause it to be postponed further. It merely copes with its likely delay.

Documentation Considerations

Fewer exo meta-operations to document.

Testing Considerations

Fewer exo meta-operations to test. In particular, testing the outcome of fixing Agoric/agoric-sdk#2070 would have been interesting ;) .

Upgrade Considerations

For this PR itself, none. For Agoric/agoric-sdk#2070 , it would be good to be able to upgrade a durable non-revocable exo class to a revocable one, and perhaps even vice versa. The receiveRevoker API was designed to be consistent with that. But the real question is the representation of potentially revocable durable objects.

[mhofman]

This change is flagged as fix(exo)!: because it is a compat break. But we are unaware of any uses in production, so it may be a compat break only in theory.

I'm wondering if we need a way to flag some new additions as experimental, allowing us to have breaking changes without semver major bumps. I think this is another one of these case which doesn't warrant triggering a major version.

[erights]

This change is flagged as fix(exo)!: because it is a compat break. But we are unaware of any uses in production, so it may be a compat break only in theory.

I'm wondering if we need a way to flag some new additions as experimental, allowing us to have breaking changes without semver major bumps.

Sounds plausible!

I think this is another one of these case which doesn't warrant triggering a major version.

Changed to fix(exo):. Done, thanks.

[FUDCo]

Looks legit to me.