native-messaging-quickjs VS offscreen-webrtc

QuickJS https://github.com/guest271314/native-messaging-quickjs (after strip the executable is less than 1MB; the last time I checked node executable is well over 80MB) to run ImageMagick and pipe the result to local file system, remote end-point, or to the browser as a stream.

Dynamically set arbitrary Web pages as "externally_connectable" and forward messages from the Web page to Native Messaging host the forward messages from Native Messagin host back to arbitrary Web page https://github.com/guest271314/native-messaging-quickjs/tree/dynamic-externally-connectable

I can ship qjs in a browser extension with no undue constraint on storage, and run qjs from the browser from any Web site https://github.com/guest271314/native-messaging-quickjs/tree/dynamic-externally-connectable. That is a different story for node and deno, when we really analyze the built-ins we use, do not amount to all of the built-ins, however, there is no way that I am aware of to reduce the size of V8 engine; even d8 is what, 20MB, and not simple to extend to actually use stdin, stdout.

Working JavaScript (QuickJS) version: https://github.com/guest271314/native-messaging-quickjs/blob/main/nm_qjs.js

A QuickJS Native Messaging host that echoes input https://github.com/guest271314/native-messaaging-quickjs from client. Have fun.

Using an extension we can create an offscreen document, connect to a Native Messaging host, stream stdin to a local application, and stream stdout to the browser (Web page), see offscreen-webrtc.

There are multiple ways to upload and send files, including WebRTC datachannels, e.g., https://github.com/guest271314/offscreen-webrtc, WebTransport, WebTorrent https://github.com/jeremyckahn/secure-file-transfer, WebSocket, WebSocketStream, or just using Fetch and Streams. fetch() on Chromium-based browsers also supports duplex:'half' in request init for bi-directional streaming capability.

To achieve this specific task, once an HTML page is loaded into the browser, and a ServiceWorker is registered for that scope, the server does not need to remain active to maintain the functionality of intercepting requests from the Web page (popup window) to the ServiceWorker, where the ServiceWorker can itself make requests to, for example, the same local server to execute parec and pipe output to multiple EventSource responses within the same initial connection, or pipe data to a single ReadableStream served with Response() and event.respondWith(), e.g., see https://github.com/guest271314/offscreen-webrtc, https://github.com/guest271314/sw-transfer-stream.

I've already built it https://github.com/guest271314/captureSystemAudio#web-accessible-resources-transferable-streams-media-capture-transform-breakout-box, https://github.com/guest271314/captureSystemAudio/blob/master/native_messaging/capture_system_audio/capture_system_audio.js; see also https://github.com/guest271314/sw-transfer-stream and https://github.com/guest271314/offscreen-webrtc. I'm just trying to reduce steps https://github.com/guest271314/requestClient.

Yes, you can create an iframe and/or a new window that you have complete control of to execute arbitrary code using either localhost or an extension; e.g., https://github.com/guest271314/sw-transfer-stream, https://github.com/guest271314/offscreen-webrtc.

Yes. You can use WebRTC. See https://gist.github.com/guest271314/53e00c6765aa256362fb52c08e82d189, https://github.com/guest271314/offscreen-webrtc.

Establish WebRTC connection between offscreen document and arbitrary Web page to transfer data from ServiceWorker to Web page https://github.com/guest271314/offscreen-webrtc

There are workarounds which involve using an iframe https://github.com/guest271314/persistent-serviceworker/tree/main/chromium_extension_web_accessible_resources_iframe_message_event or window.open() https://github.com/guest271314/sw-transfer-stream or and offscreen document https://github.com/guest271314/offscreen-webrtc with WebRTC - however that involves loading an entire HTML document, and each has its own deficienfies - with all of the Window features that we do not really need just to transfer data between the Web page I have control of and the ServiceWorker I have control of.