feat(ocap-kernel): use kernel platforms

[grypez]

This PR integrates the @ocap/kernel-platforms package across the various monorepo packages which should use it, enabling platform-specific capabilities and endowments for vats. The platformOptions parameter is supplied by the vat worker constructing the vat's supervisor, while the platformConfig parameter is delivered from the kernel as part of the vat initialization command.

Key Changes

• Extend VatSupervisor to accept optional makePlatform and platformOptions parameters
• Extend VatConfig type to include optional platformConfig field
• Integrate platform endowments into vat initialization
• Integrate platform factories in browser and Node.js runtimes

Note to Reviewers

This diff shows how to endow a host-constrained fetch capability to a vat.

[grypez]

The constrained fetch is endowed i.e. available in the global namespace of the vat.

[rekmarks]

A couple of questions.

@grypez do you mind putting up a draft of how you're using this feature so reviewers can better understand where this is going?

Update: Or ah, that's what this diff is?

[rekmarks]

Should we just throw an error in case of collisions here instead?

[grypez]

Sure. That would be less silent. Since the comment only makes explicit the strategy we already employed, I think this can be its own (small) issue.

[rekmarks]

Specifying platform endowments that collide with inescapable global properties should be forbidden. I would prefer if we make this validity check here, or at least create a high-priority issue to it immediately after this PR is merged.

[grypez]

Made a start here, and welcome further discussion and finer requirements.

[sirtimid]

perhaps we can do a dynamic import and use it directly inside VatSupervisor like we do here (you can make a utility isNodeEnv())? It's not ideal that we are making users do this.

[grypez]

I don't think we are making users do this.

There is certainly a tradeoff between explicitness and simplicity. IMO we should prefer statically analyzable dependencies for the TCB, which in our model includes the worker files. The vat usercode is outside the TCB, and remains simple, i.e. agnostic to these choices.

That said, we should package together choices which must be made jointly but are kept separate for maintainability. See makeNodeJsVatSupervisor for an ergonomic alternative to new VatSupervisor({ ... }).

We can ultimately offer a handful of out-of-the-box workers that provide most users with an ocap kernel that 'just works'.

[rekmarks]

Hm, this is partially my fault. On second thought, I think we shouldn't force users to specify platform capabilities (i.e. it should be an optional feature). It's not ideal that you can specify a platform config to a vat that cannot satisfy it, but that's okay for now. We should probably store some kind of vat metadata on the kernel side to know which platform capabilities a vat has, if any.

Here's a diff to make the makePlatform argument optional again, but more succinctly:

diff --git a/packages/ocap-kernel/src/VatSupervisor.ts b/packages/ocap-kernel/src/VatSupervisor.ts
index 43e3a194..7e40255f 100644
--- a/packages/ocap-kernel/src/VatSupervisor.ts
+++ b/packages/ocap-kernel/src/VatSupervisor.ts
@@ -41,7 +41,7 @@ type SupervisorConstructorProps = {
   id: VatId;
   kernelStream: DuplexStream<JsonRpcMessage, JsonRpcMessage>;
   logger: Logger;
-  makePlatform: PlatformFactory;
+  makePlatform?: PlatformFactory;
   platformOptions?: Record<string, unknown>;
   vatPowers?: Record<string, unknown> | undefined;
   fetchBlob?: FetchBlob;
@@ -105,7 +105,9 @@ export class VatSupervisor {
     kernelStream,
     logger,
     vatPowers,
-    makePlatform,
+    makePlatform = () => {
+      throw new Error('No platform capabilities provided');
+    },
     platformOptions,
     fetchBlob,
   }: SupervisorConstructorProps) {

[grypez]

We should probably store some kind of vat metadata on the kernel side to know which platform capabilities a vat has, if any.

We store the vatConfig for each vat, and the platformConfig is a part of the vatConfig.

[rekmarks]

This could use a test for the error thrown since 1099f48. Once that and the merge conflicts are fixed I'll approve!

[grypez]

This could use a test for the error thrown since 1099f48. Once that and the merge conflicts are fixed I'll approve!

I think it is due to an architectural constraint that we don't unit test VatSupervisor.#initVat, but I promise to add a test for missing platform in the e2e tests PR.

[rekmarks]

LGTM!