feat(extension): Add distributed object capability programming

[grypez]

Refs: #23

Title technically correct.

> await kernel.capTpCall('whatIsTheGreatFrangooly', [])
< "Crowned with Chaos"

This establishes a CapTP connection using @endo/captp over @ocap/streams between the offscreen document and the (currently singular) iframe. The iframe exposes a bootstrap object with a single method, which is called by the offscreen.

Status

• unresolved messages are not handled on delete, but they are enumerated and complained about
• capTp is unit tested by a mock of the above process
• not unit tested:
  • background.ts
  • offscreen.ts
  • iframe.ts

• The implementation could use a lot of cleanup.
• In particular I'm not committed to the current stream multiplexing implementation via StreamPayloadEnvelope.label.
  This ensures separate handling for Command and CapTP messages, which we need, but the current implementation is unlikely the ideal one.

• the envelope solution is explicit and works well; I don't recommend fixing it

[socket-security]

No dependency changes detected. Learn more about Socket for GitHub ↗︎

👍 No dependency changes detected in pull request

[grypez]

@SocketSecurity ignore npm/@endo/captp@4.3.0 npm/@endo/exo@1.5.3 npm/@endo/patterns@1.4.3

We have a close working relationship with the @Endo contributors and can rely on them for defensively correct implementations.

[grypez]

@SocketSecurity ignore npm/rimraf@3.0.2

We explicitly require rimraf^6.0.1

[rekmarks]

Looks good overall! See inline comments.

[rekmarks]

Good idea to put this in an enum, but might I suggest MessageTarget instead for the name?

[grypez]

How about ExtensionMessageTarget?

[rekmarks]

That'd work, although we're in the extension package, and there is only one kind of message. Also, if we do ExtensionMessageTarget, we should rename MessageId to ExtensionMessageId. Do you see a need to disambiguate it from anything in particular?

[grypez]

I do.

The word Extension in this enum is to clarify that there are a finitely enumerable set of targets to which one can send an ExtensionMessage, and those targets are enumerated by ExtensionMessageTargets. The underlying extension framework responds to the targets 'background' and 'offscreen', so these are extension targets.

MessageId is only used when sending messages to iframes, or in this implementation the iframe. As we approach $n$ iframes, I want to reserve the possibility of targeting a particular vat's iframe using the target key. That may be a faulty reservation. But in any case we don't use MessageId when sending an ExtensionMessage, so we shouldn't rename it to ExtensionMessageId.

[rekmarks]

Ship it!