Better platform support

[v1rtl]

Platform support

Desktop / server

• NetBSD — currently fails due to a native linking dep (getrandom/ring/libp2p crypto wiring). Best-supported remaining BSD.
• Windows — IPC daemon is supported on Windows 11 (see research comment below: tokio named pipes recommended).

Mobile (client-embedding only, not daemon)

Embedded in an app via FFI (JNI on Android, Swift/C ABI on iOS), using the in-process HoverflyClient model (same as the wasm build, not daemon.rs). Node lifetime = app foreground lifetime (e.g. a browser app whose node runs only while the browser is open). Outbound-only; no IPC daemon, no inbound node (NAT/CGNAT makes a phone node pointless anyway).

• Android (tier 2, aarch64-linux-android primary) — Linux underneath so #[cfg(unix)] compiles; build via cargo-ndk. A long-lived background node is technically possible (foreground service + REQUEST_IGNORE_BATTERY_OPTIMIZATIONS) but unnecessary and Play-Store-restricted — foreground-lifetime embedding is the right model.
• iOS (tier 2, Apple Silicon: aarch64-apple-ios + -sim) — daemon-less by hard platform constraint (no persistent background user processes). Foreground-lifetime embedded client only.

Other

• Raspberry pi already covered by aarch64
• EFI? (would need a separate no_std implementation)

Shared blocker across BSD/mobile targets

Native deps gate most of these: getrandom (per-OS entropy syscall), rustls via ring (spotty BSD asm), and libp2p crypto (noise/secp256k1). Resolving the rustls/ring backend likely unblocks several targets at once.

[v1rtl]

Windows IPC daemon — research notes

Investigated whether the daemon (src/daemon.rs) IPC can be made to work on Windows 11 rather than excluded.

Current state

• The IPC surface is small and transport-agnostic: UnixListener/UnixStream (tokio) + a u32-LE length prefix + JSON frame protocol. The frame helpers (read_frame/write_frame) only need AsyncRead + AsyncWrite, not specifically a Unix socket.
• The whole module is #[cfg(unix)]-gated in lib.rs:61, and the CLI exposes it via --socket <path>.
• Connection-per-request, one request → one response → close. Not a security boundary.

Windows 11 options

1. interprocess local sockets — cross-platform, keeps the filesystem-path semantics on both OSes (Unix domain socket on Unix, named pipe on Windows). Smallest diff to the existing --socket <path> API. Not the tokio family.
2. tokio built-in named pipes (tokio::net::windows::named_pipe) — no new dependency, most idiomatic on Windows, stays in the tokio family. Recommended. Addressing changes from a filesystem path to a \\.\pipe\… name, and you create a server instance per connection instead of accept()-ing one listener.

Recommended shape: make handle_conn/call/frame fns generic over AsyncRead + AsyncWrite + Unpin (they nearly are already) and cfg-split only the listener/stream types: #[cfg(unix)] keeps Unix sockets, #[cfg(windows)] uses tokio named pipes.

Not yet done

Compile verification for x86_64-pc-windows-msvc was not completed (target + cargo-xwin not set up; cross-building the full native tree — libp2p/reqwest/rayon — is heavy). Cleanest verification path is an isolated minimal probe crate replicating the IPC pattern, cross-compiled with cargo-xwin, before touching the real module.

Conclusion: Windows IPC daemon support is feasible and need not be excluded — option 2 (tokio named pipes) is the lowest-risk path.