feat(zoe): prepare-ownable-object

[erights]

Staged on #8020

Alternative to #8022 with improved support API

closes: #XXXX
refs: #8020 #8022 #8021 #8682

Description

The basic idea of an "ownable object" is to provide general and lower level support for approximately the pattern that vaults implement manually in an adhoc manner: A ownable object is an object with a makeTransferInvitation method that revokes the object itself, in the sense of inactivating it — it no longer provides any authority. Instead, the exclusively transferable portion of its authority is encapsulated by the returned invitation, in an allegedly legible manner. That invitation can be redeemed, via an offer , for a new ownable object in which the transferable authority from the original ownable object is now exercisable.

We call this an "ownable object" since the rights of ownership include

• the right to exercise (use)
• the right to exclusively transfer the rights of ownership
• the right to exclude others from being able to exercise and transfer
• the ability to legibly offer the exclusive transfer of ownership

Objects are about rights to exercise (use) and share, but not transfer, and not legibly.

ERTP is about legible exclusive transfer but not exercise.

The lifecycle of an ownable object, transmuting between an ephemeral ownable object and an invitation to get a new “equivalent” ownable object, combines all attributes together. But the attributes are never directly present at the same time. That’s why it is the lifecycle that combines these.

This notion of "ownable" and "ownership rights" has strong echoes in programming language notions of "ownership types", "linear types", and "affine types". However, none of these, as far as we are aware, has the two-phase lifecycle of our ownable objects. Nor do they provide for legibility of offers to transfer, which is crucial for secure exchange and offer safety.

See Necessity specifications for robustness

See https://groups.google.com/g/cap-talk/c/9OU9ZNoB3os/m/gXeu2zs4AgAJ?utm_medium=email&utm_source=footer for a useful real-world analogy for the two-phase ownership cycle.

Security Considerations

Must ensure that revocation really denies all further authority from the original ownable object, even from messages that are already in the air but not yet delivered.

Need to verify that the legibility can meet invitation legibility goals.

Scaling Considerations

Switching much usage to revocables and ownables should have big scaling benefits, but this remains to be measured.

Documentation Considerations

Once ready to be used, not only should this be documented, we should be able to simplify several other APIs in ways that should make them more explainable.

Testing Considerations

Need to test the hell out of this.

Upgrade Considerations

The transfer invitations have durable handlers and so are themselves durable and should survive upgrade.

The ownable objects themselves are defined to be durable, so they can survive upgrade.

The prepareOwnableClass should be able to upgrade a conventional object that had previously been defined with prepareExoClass using the same baggage and kindName.

[erights]

Superseded by #8745 , so reverting to draft

[erights]

Closing in favor of #8745