pyo3 feature force-includes transport-reticulum → Unix-only reticulum-std blocks Windows wheels (edge + all pyo3 consumers)

[emooreatx]

Surfaced building CIRISLensCore's Windows wheel (CIRISLensCore#43.3, "no deferring Windows"). Blocks Windows for edge's own pyo3 wheel and every pyo3 consumer (lens-core, and anything enabling ciris-edge/pyo3).

Root cause

Edge's pyo3 feature hard-includes transport-reticulum:

pyo3 = [ "dep:pyo3", "dep:pyo3-async-runtimes", "dep:pyo3-stub-gen",
         "ciris-persist/pyo3", "transport-reticulum", ... ]

transport-reticulum pulls reticulum-std (Leviculum, optional=true), which is Unix-only — on windows-x86_64 the build fails with:

error[E0433]: cannot find `UnixListener` in `net`
error[E0433]: cannot find `unix` in `os`   (std::os::unix::net::UnixListener)
error[E0425]: cannot find function `if_nametoindex` in crate `libc`
error: could not compile `reticulum-std` (lib) due to 12 previous errors

A consumer enabling ciris-edge/pyo3 cannot subtract transport-reticulum (Cargo features are additive), so this is not fixable downstream. lens-core needs ciris-edge/pyo3 for the frozen install_relay API, so it can't drop it either.

Ask (either fixes it)

1. Decouple pyo3 from transport-reticulum — a pyo3 wheel shouldn't force the Reticulum transport. Let consumers opt into transport-reticulum separately (it's already a feature). The PyEdge surface (engine/capsules/handler dispatch) doesn't need the Reticulum interface compiled to exist. OR
2. Make reticulum-std Windows-portable (Leviculum) — gate the Unix-socket/if_nametoindex paths behind cfg(unix) with a Windows TCP-only path, so the crate compiles (Reticulum AutoInterface/Unix features no-op on Windows).

(1) is the lighter cut and unblocks Windows pyo3 wheels immediately. Edge's own Windows pyo3 wheel hits this too (if edge ships one).

Context

• Does edge currently ship a Windows pyo3 wheel? If so it should be failing on the same reticulum-std error; if not, that's the same gap.
• lens-core already bundles OpenSSL on Windows (target.'cfg(windows)' openssl/vendored — the other transitive Windows blocker, via reqwest); that part builds. reticulum-std is the remaining wall.

cc CIRISLensCore#43.3, CIRISEdge#85 (cohabitation handshake).

[emooreatx]

Filed upstream: CIRISAI/leviculum#10 — concrete diagnosis of the 2 Unix-only call sites blocking reticulum-std on Windows + proposed cfg-gate + Windows stub path (minimum viable: ~50 lines, unblocks Windows wheel; AutoInterface degrades to OS-default-iface; LocalInterface unavailable on Windows but TCP/UDP/RNode/Serial all stay portable).

Per that issue's analysis, option (2) here ("Make reticulum-std Windows-portable (Leviculum)") is the cleaner answer than option (1) (decouple pyo3 from transport-reticulum): when leviculum#10 lands, edge needs zero source changes — every downstream consumer (lens-core's Windows wheel; agent 2.9.6 Windows surface) unblocks transparently. The decoupling approach would fan out CI matrices across consumers + require operator config changes to opt back into transport-reticulum on Unix.

Will hold edge#87 open as the consumer-side tracking ticket until leviculum#10 closes, then re-pin edge's leviculum dep to whatever revision carries the port + verify the wheel builds on windows-x86_64.

[emooreatx]

Upstream fix landed — Windows now builds.

reticulum-std was Unix-only at three call sites (the issue named two; rpc/mod.rs was the third), which is what broke the pyo3 wheel on windows-x86_64. Fixed upstream in Leviculum and merged to main (CIRISAI/leviculum#11, commit 4c15dfd, closes CIRISAI/leviculum#10):

• local.rs (LocalInterface IPC) and rpc/mod.rs (the multiprocessing.connection RPC server) now use TCP loopback on Windows, mirroring Python-RNS's own AF_INET fallback (ports 37428/37429). The Unix abstract-socket path is unchanged.
• auto_interface name_to_index uses iphlpapi::if_nametoindex on Windows.

No Named-Pipes work was needed — Python-RNS itself uses TCP loopback when AF_UNIX is unavailable, so this is the wire-compatible target.

Validated on a real windows-latest (MSVC) CI runner, not just compiled: reticulum-core + reticulum-std build, 212 lib tests pass, and a new end-to-end test drives real Python-RNS get_interface_stats() over the TCP-loopback RPC — proving the pickle/umsgpack + HMAC wire format interoperates on Windows. A windows-latest job is now part of Leviculum CI to keep it green.

Edge action: bump the transport-reticulum/reticulum-std pin to include 4c15dfd and the pyo3 Windows wheel should compile. Ping me if the maturin/NDK side surfaces anything else.

[emooreatx]

Resolved in v2.1.1 via option 2 (Windows port of reticulum-std), not option 1.

Cherry-picked leviculum#10 + #11 (Cargo.toml:414-415, leviculum 4c15dfd) — gates UnixListener / if_nametoindex behind cfg(unix) and ships a Windows-portable build of reticulum-std. The pyo3 ↔ transport-reticulum coupling stays (it's the right shape — the PyEdge Reticulum surface is what consumers like lens-core actually exercise), but the dependency now compiles on windows-x86_64.

Subsequent catch-up (leviculum ded96eeb in v2.1.2) is still in effect, and the Windows wheel CI lane has been green every release cut since (most recently linux-x86_64/Windows wheels on PR #101 / v2.3.0 cut). Windows pyo3 wheel ships on PyPI as ciris_edge-X.Y.Z-cp310-abi3-win_amd64.whl.

LensCore + every other ciris-edge/pyo3 consumer was unblocked at that point.