Bohdan Triapitsyn
859b4529da
Adds OpenChamber Relay — an opt-in way to reach an instance from a phone, browser, or another desktop from anywhere, with no open inbound ports, no tunnel, and no shared LAN. The instance dials outbound to a relay; all app traffic (HTTP, the event stream, terminal, dictation) is multiplexed and encrypted through a single connection per client, so the relay only ever forwards opaque ciphertext. Transport - End-to-end-encrypted channel over WebCrypto (ECDH P-256 -> HKDF -> AES-256-GCM) with a capability-negotiated handshake and a small HTTP/SSE/WebSocket multiplexing protocol. A byte-compatible JS host mirror is cross-checked by tests. - Host: outbound connection manager, per-client tunnel dispatcher to the local server over loopback, reuse of the existing instance identity key, and management routes. Disabled by default; explicit opt-in. - Client: plugs into the existing runtime layer (runtime-fetch/-url/-switch/ -auth, event pipeline, terminal, dictation) so features work over the relay unchanged; direct-URL and Electron realtime-proxy paths are untouched. Pairing & UX - Relay section in Settings -> Remote Instances (live status, QR/link pairing, revocation via the existing client-token list) and the mobile connect flow. - Frame batching and idle-gated keepalive keep tunnel message volume low without affecting streaming smoothness. Security - The tunnel is transport only; the server authenticates every tunneled request exactly as for a direct remote client. fragments only. The relay stores no keys, tokens, or payloads. Operability - The endpoint can be pinned to a self-hosted rel paired clients inherit it from the offer automatically. - Relay module DOCUMENTATION.md and a relay-trans invariants that future WebSocket/streaming changes must follow. The relay transport is complete and tested; the UI for enabling and pairing is gated behind openchamber_relay_gate and stays
123 lines
6.0 KiB
Markdown
123 lines
6.0 KiB
Markdown
# CLI Module Map
|
|
|
|
This directory contains the non-entrypoint implementation for the OpenChamber CLI. `packages/web/bin/cli.js` should stay thin: it owns bootstrap, command wiring, top-level dispatch, signal/cancel handling, and compatibility exports. Domain logic belongs in these modules.
|
|
|
|
## Entrypoint Boundary
|
|
|
|
- `../cli.js`
|
|
- Owns process bootstrap, package/version lookup, command table wiring, signal handlers, top-level error handling, and legacy exports used by tests or external consumers.
|
|
- Injects runtime dependencies into command factories, such as `serveCommand`, `stopCommand`, package-manager loading, cancel cleanup, and foreground server state setters.
|
|
- Should not grow command-specific behavior. If a new branch needs more than dispatch/wiring, move it here into a command or helper module instead.
|
|
|
|
## Command Modules
|
|
|
|
Command modules implement user-facing commands and preserve output contracts across interactive, non-TTY, `--quiet`, and `--json` modes. They should use `../cli-output.js` for presentation helpers and keep safety validation in command logic, not prompts.
|
|
|
|
- `commands-serve.js`
|
|
- Implements `openchamber serve`.
|
|
- Owns OpenCode CLI checks, port resolution, log rotation, PID/instance registry writes, foreground/background server launch, startup summaries, and foreground shutdown behavior.
|
|
|
|
- `commands-lifecycle.js`
|
|
- Implements `openchamber stop` and `openchamber restart`.
|
|
- Owns lifecycle stop/restart semantics, desktop-managed port rejection, unmanaged instance shutdown attempts, PID/instance cleanup, and restart reuse of stored instance options.
|
|
|
|
- `commands-status.js`
|
|
- Implements `openchamber status`.
|
|
- Formats discovered instances and tunnel readiness/status for human, quiet, and JSON output.
|
|
|
|
- `commands-logs.js`
|
|
- Implements `openchamber logs`.
|
|
- Resolves log files, tails recent lines, and follows log output.
|
|
|
|
- `commands-startup.js`
|
|
- Implements `openchamber startup`.
|
|
- Handles startup subcommand dispatch and presentation around the lower-level startup service helpers.
|
|
|
|
- `commands-connect-url.js`
|
|
- Implements `openchamber connect-url`.
|
|
- Finds or starts a local instance and prints the browser/connect URL according to the selected output mode.
|
|
- `--relay` builds an end-to-end-encrypted relay pairing link instead: it mints a client token and an offer from the instance's local relay identity (no server URL, no auto-start). The relay endpoint follows `OPENCHAMBER_RELAY_URL` / the stored setting / the default, matching the running host; clients read it from the offer.
|
|
|
|
- `commands-update.js`
|
|
- Implements `openchamber update`.
|
|
- Loads the package-manager helper, performs update flow, and coordinates restart behavior after updates.
|
|
|
|
- `commands-tunnel.js`
|
|
- Implements `openchamber tunnel` and its subcommands: `profile`, `providers`, `ready`, `doctor`, `status`, `start`, `stop`, and `completion`.
|
|
- Owns tunnel-specific command flow, interactive prompt decisions, managed-local/managed-remote startup, QR display rules, tunnel start/stop API calls, and tunnel profile command handling.
|
|
- Receives `serveCommand` and `stopCommand` by dependency injection. Do not reach back into `cli.js` command globals from this module.
|
|
|
|
## Shared Helper Modules
|
|
|
|
These modules hold reusable, non-presentational logic for commands.
|
|
|
|
- `cli-args.js`
|
|
- Argument parsing, defaults, help text, completion script generation, and typo suggestions.
|
|
|
|
- `cli-errors.js`
|
|
- CLI exit codes and typed tunnel CLI errors.
|
|
|
|
- `cli-paths.js`
|
|
- Data, run, log, settings, tunnel profile, and managed-local config paths.
|
|
|
|
- `cli-process.js`
|
|
- PID files, instance registry files, process identity checks, runtime metadata checks, and process termination helpers.
|
|
|
|
- `cli-lifecycle.js`
|
|
- Instance discovery, live health probing, attachability checks, provider discovery, and status aggregation used by lifecycle/status/tunnel commands.
|
|
|
|
- `cli-http.js`
|
|
- HTTP helpers for health checks, shutdown requests, JSON API calls, tunnel provider fetches, and system info fetches.
|
|
|
|
- `cli-network.js`
|
|
- Host resolution, URL building, LAN detection, unsafe browser port validation, and UI password/network exposure checks.
|
|
|
|
- `cli-ports.js`
|
|
- Port availability checks and available-port resolution.
|
|
|
|
- `cli-log-files.js`
|
|
- Log rotation, tail reads, and file-follow streaming.
|
|
|
|
- `cli-executables.js`
|
|
- Executable path resolution and PATH lookup helpers.
|
|
|
|
- `cli-startup.js`
|
|
- Native startup service detection, install/uninstall/status helpers, and platform-specific startup command execution.
|
|
|
|
- `cli-tunnel-profiles.js`
|
|
- Tunnel profile normalization, token resolution/redaction, profile storage, migration, file-permission warnings, and managed-remote pair persistence.
|
|
|
|
- `cli-tunnel-utils.js`
|
|
- Tunnel-specific command string builders, TTL parsing/formatting, and replay command helpers.
|
|
|
|
- `cli-tunnel-capabilities.js`
|
|
- Built-in tunnel provider capability fallbacks used when a live server cannot provide tunnel metadata.
|
|
|
|
## Placement Rules
|
|
|
|
- Add new CLI commands as `commands-*.js` modules and wire them from `cli.js`.
|
|
- Add reusable logic to the narrow helper module that owns the domain. Create a new helper module before mixing unrelated domains into an existing one.
|
|
- Keep command modules responsible for user-visible behavior and mode-specific output. Keep helper modules mostly output-free unless the helper exists specifically for CLI rendering.
|
|
- Preserve output contracts when moving code:
|
|
- `--json` emits JSON only.
|
|
- `--quiet` emits concise essential output.
|
|
- Prompts are gated by `canPrompt(options)`.
|
|
- Validation and policy run in every mode.
|
|
- Prefer dependency injection from `cli.js` for cross-command behavior, especially when one command needs another command's implementation.
|
|
- Do not import `cli.js` from modules in this directory. The dependency direction is `cli.js` -> command modules -> helper modules.
|
|
|
|
## Verification
|
|
|
|
For CLI behavior changes, run the focused CLI suite from `packages/web`:
|
|
|
|
```sh
|
|
bun run test -- bin/cli.test.js
|
|
```
|
|
|
|
Before finalizing source changes that affect CLI behavior, also run:
|
|
|
|
```sh
|
|
bun run type-check
|
|
bun run lint
|
|
```
|