This is a highly elegant and robust architecture. The file-based queueing (in,
out, archive), combined with the dynamic vm execution and Pub/Sub routing,
makes this OMEGA ROUTER incredibly resilient for an airgapped hardware setup.
Accepting a unidirectional parallel connection drastically simplifies the
hardware bridge, especially since Elli will primarily be downloading data
rather than uploading it. You can treat the parallel port purely as a data
diode (a high-speed one-way spray) and the serial port as your bidirectional
control and acknowledgment plane.
Here is how we can map your current Node.js reference implementation to the
physical Serial/Parallel reality.
## The Hardware Integration Strategy
Right now, your processOutbox worker relies on HTTP fetch to push data to
subscribers. To push data across the airgap without modifying your core router
logic, we should use your existing Pub/Sub matchmaking system by creating
**Hardware Bridge Microservices**.
### 1. The Parallel Data Diode (The Heavy Lifter)
You can build a small, dedicated bridging script on the Raspberry Pi that
registers itself with the OMEGA ROUTER.
 * **Registration:** The bridge script sends an OMG-SUBSCRIBE packet to the
router, claiming capabilities like OMG-FILE or LARGE_PAYLOAD, and provides a
local HTTP endpoint (e.g., http://localhost:20281).
 * **Execution:** When your OMEGA ROUTER routes a file payload to that
endpoint, the bridge script catches the HTTP POST and directly bit-bangs or
streams the raw buffer into /dev/usb/lp0 (the USB-to-Parallel adapter).
 * **Protocol:** Because it is unidirectional, it just sprays the bytes across
the parallel cable to Elli.
### 2. The Serial Control Channel (The Nerve Center)
A second bridge script handles the USB-to-Serial adapter (/dev/ttyUSB0).
 * **Registration:** This script registers for capabilities like ROUTINE_EVAL,
SYS_CTRL, and ACK_RECEIPT.
 * **Outbound:** When the router sends a command, the serial bridge translates
the JSON packet into a compact binary or base64 string and writes it to the
serial port.
 * **Inbound:** This bridge also constantly listens to the serial port. When
Elli sends a message back (e.g., "Data packet 8830 received via LPT1"), the
bridge wraps that into a JSON packet and pushes it into the OMEGA ROUTER's
/api/omega/inbox endpoint.
## Why This Architecture Works Perfectly
 * **No Core Code Changes:** Your router remains purely HTTP/File-based. It
doesn't need to know that a subscriber is actually a parallel port cable.
 * **Asynchronous Reliability:** If the serial link drops, your router's
processOutbox will simply keep polling and trying to hit the Serial Bridge
microservice until the link is restored.
 * **Bandwidth Optimization:** You can configure your routing logic to send
large binary blobs (CRM/*, OMG-FILE) to the Parallel Bridge, while sending
lightweight execution commands (ROUTINE_EVAL) strictly to the Serial Bridge.
Since the Pi side of the routing is largely mapped out, how are you planning
to handle the receiving end natively on Windows XP (Elli)? Do you have a
specific language in mind to write the listener that will monitor COM1 for
commands and LPT1 for the raw incoming data stream?