Questions for API review

Frontend creation has different defaults

SOCKS generates credentials by default. HTTP is unauthenticated when endpoint is NULL, and HTTP rewriting is false unless explicitly enabled. Apple and Linux start SOCKS first partly to obtain credentials that HTTP can reuse; Windows generates them independently.

Would an explicit, shared credential-creation policy make HTTP-only browser startup clearer?

Lifecycle symmetry and callback queues

SOCKS has start/stop/restart and leases. HTTP has start/destroy, with mobile HTTP leases implemented in the adapter. HTTP lifecycle callbacks use the HTTP queue while forwarding and recovery use the control queue. The HTTP header describes start callbacks as running on its queue, but the implementation reports start-allocation failure synchronously on the caller’s queue. This documentation records that exception. HTTP must finish destruction before the host destroys the pool; SOCKS destruction can be submitted immediately before pool destruction.

Are these distinctions appropriate to expose, or should a small common frontend contract hide some of them? Any change must preserve the ability to share a pool among independent listeners.

Remaining public naming and string exceptions

Pool commands still use names such as OuterSSHProxyCommandHandler, OuterSSHProxyCommandResultValue, and OuterSSHProxyError. They work without a proxy. HTTP realm is a NUL-terminated exception to the byte-counted API convention.

These are concrete places to consider a naming/consistency pass; the documentation deliberately uses the existing names.

Error and compatibility behavior differ across adapters

macOS installs rich frontend failure reporting; iOS, Linux, and Windows currently do not. Apple installs a dynamic loopback URL compatibility script; Linux and Windows currently rely on their navigation adapters and the C proxy’s more limited HTTP rewriting.

These are adapter differences, not necessarily missing library features. Converging them could make the browser contract more consistent without adding more C APIs. Failure callbacks have no navigation identifier, and socket availability has no separate “unknown” notification; consumers currently need their own correlation/state policy.

Trust, authorization, and application policy

The library permits a NULL host-key validator, which accepts keys. Direct-socket authorization is cached until pool destruction; there is no public cache invalidation operation. Sudo recovery and host-key validation both use completions that may be invoked asynchronously. Cancellation while a prompt is open remains the host’s responsibility.

These are intentional or existing choices with user-visible consequences. They should be evaluated as policy/API decisions rather than hidden in browser-specific glue. The allowlist paths themselves still carry Outer Loop product names even though OuterSSH is reusable.

Rewriting is a compatibility subset

The proxy does not reverse-rewrite arbitrary response headers, compressed HTML, external JavaScript, or HTTPS. Browser scripts cover additional cases on Apple. Before expanding that behavior, decide which localhost-oriented application patterns belong in the library contract and which should remain browser compatibility features.