@appport/transport-electron

The Electron IPC transport: main-process binding, preload bridge and renderer transport, over a single generic channel.

// main process
import { ipcMain } from "electron";
import { serveElectronIpc } from "@appport/transport-electron";

serveElectronIpc({
  server,
  ipcMain,
  validateSender: (event) => event.senderFrame?.url?.startsWith("file://") ?? false,
  identify: (event) => resolveIdentity(event)
});

// preload.cjs
const { contextBridge, ipcRenderer } = require("electron");
const { exposeAppPort } = require("@appport/transport-electron/preload");

exposeAppPort(contextBridge, ipcRenderer);

// renderer
import { createElectronTransport } from "@appport/transport-electron";

const transport = createElectronTransport(); // uses window.appport

Why one channel

The AppPort envelope identifies the capability, so there is one IPC channel, appport:message, not one per operation. Channels named save-document and open-document would put the application API into the transport, which is what the protocol exists to prevent.

Why a bridge, not ipcRenderer

Electron's guidance is to expose narrowly scoped context-bridge APIs; exposing ipcRenderer grants arbitrary message access. The bridge here is two functions: send an envelope, receive envelopes.

Trust

IPC is not identity. validateSender decides whether a frame may speak AppPort at all, identify resolves the session, and every capability is still authorized. Envelopes queue behind identity resolution, so the first request is never dispatched as anonymous.

The package depends on structural types rather than on electron, so the same build works in the main process, the preload script and the renderer — and so the transport can be tested without launching a browser.