Implement makePublisherKit for sealed publishers

[gibson042]

What is the Problem Being Solved?

Agents such as the on-chain wallet need access to notifiers that may convey private data or closely-held objects.

Description of the Design

Consuming code with access to a sequence of sealed data messages and a (non-public) "unsealer" facility can make a Notifier for each message in the sequence that has been extracted using the unsealer. Code with access to a Notifer and a (non-public) "sealer" facility that is the complement of the unsealer can make a sequence of sealed data messages, one per result of the Notifier.

One such sealer/unsealer is a marshal serialize/unserialize which produces and consumes slots according to a private namespace or clist. Another one may use a public namespace.

We can go further and extend this support to Subscriptions as well as Notifiers, with the pattern of composing a Notifier<[sealedCurrentState, Subscription<sealedDelta>]> where the latest notifier state can be queried to conserve bandwidth.

Security Considerations

Consumption of the sequence of messages without access to the unsealer must not be able to reveal any private or closely-held contents, within the limits of the actual implementation of the sealer.

Test Plan

TBD

[Tartuffo]

@gibson042 per discussion in wallet meeting, we believe this has been designed between you and @michaelfig so removing the needs-design label.

[michaelfig]

I suggest creating @agoric/publisher to export makePublisherKit and makeSubscriber

• Contracts should accept one or many publisher kits as optional private terms, and default to an unparameterised makePublisherKit which produces just the basic prefix-lossy subscription kit.
• The creator of a publisher kit would specify:
  • A jsonPublisher for JSONable-only data transport (i.e. a simple wrapper for the event stream+merkle tree storage)
  • An optional ocap sealer (e.g. obtain board IDs or clist integers for them) for marshalling and transmission via the jsonPublisher. The default sealer just throws if asked to seal an ocap.
• The sealer would also embed the recommended unsealer parameters as part of the publication so it is mostly self-describing.
• Sophisticated subscribers can inspect the publication, and override the default unsealer with their own custom version.

[Tartuffo]

Doing this differently, per #4398.