- the ASSOCIATE reply's BND.ADDR/BND.PORT is a relay handle, not a
destination (per-datagram destinations ride the datagram header);
swapping "tell the client about a UDP port" for "tell the client
about the UDP tunnel" preserves every RFC property: one channel per
association, {addr, data} frames in-band, channel EOF = association
lifetime, optional front-door binds on either side
- sentinel-address hunch superseded: no virtualized relay address is
ever needed on the in-band path; BND.ADDR there is pure
RFC-compatibility surface
- producer egress has two variants, both dial-callback policy (OQ-SK-01
shape): local UdpSocket (no flow table, native-only) or composed
per-target alktunnels udp-tunnels (lazy destination->tunnel table;
flow table reborn as channel handles; per-target ACL for free —
dissolves most of OQ-SK-05 for the composed path)
- no upstream ask: alktunnels' connected-udp substrate is correct as-is
for per-target composition; an unconnected-egress resource would be
SOCKS5 again (circular)
- POC #2 baseline settled: sketch both egress variants behind the dial
callback, measure per-destination open cost of the composed variant
- new docs/research/iroh-socks5-eval.md: full source review of
iroh-socks5 0.5.0 (github.com/mattgeddes/iroh-socks5, MIT OR
Apache-2.0) — quality verified, structural sibling of the alksocks
shape, but iroh-coupled (no generic-T seam) with an RFC subset, so
fast-socks5 stays the protocol base (POC #1/#4 conclusions stand)
- phase-0: prior-art section for iroh-socks5; OQ-SK-03 updated with its
UDP design as the POC #2 baseline (framed {addr, data} in-band
datagrams, RFC header codec at front doors only, no producer-side
flow table, control-EOF association lifetime, FRAG != 0 refused)
- POC #1 passed (alksocks-connect-poc, 8 tests + curl front-door
example): BiStream-as-T genericity, register_openable_with_
establisher fit, pump_bidi data plane, typed session refusal,
RFC reply-code dial-refusal mapping, vanilla-client front door.
Structural resolution: the dial belongs at the command-read
interception point (target is unknowable at open time); the
establisher is the session gate. OQ-SK-01/02 shapes resolved
empirically.
- POC #4 passed (fs5-wasm-poc, kept at /workspace/alksocks-fs5-wasm-poc):
the fork is genuinely minimal — ~120 lines of #[cfg] insertions
gate kernel-net behind a default-on 'net' feature; the wasm-clean
subset compiles for wasm32-unknown-unknown (--no-default-features)
and still completes a full RFC 1928 CONNECT conversation. OQ-SK-04
reduces to the adapter-story question.
- Corrected the run_udp_proxy_custom prior-art claim: it binds a
kernel socket unconditionally (relay closure + reply IP only);
the channels path drives the typestate directly. Fileable ask.
- Findings: docs/research/poc-connect-wasm-findings.md
The root question is 'does wasm make sense for alksocks?', not 'how
do we get wasm': Case 1 (wasm wanted) -> fork-first, PR as courtesy,
carry regardless; Case 2 (wasm unwanted) -> plain dependency on the
router.rs native path, no fork (the alkhttp precedent, strictly
better when its premise holds). Decision inputs written: (a) is
there a planned sandboxed (wasm) consumer of the SOCKS5 service,
(b) is the fork genuinely minimal (POC #4 checks). Fork-first is a
conditional preference, not a general one — do not carry a fork for
an invariant's sake. AGENTS.md conventions 4/17 aligned.
- phase-0 vision: components split — (1) producer half (expose the
SOCKS5 service over channels), (2) consumer half (consume it,
optionally bind it locally — the ssh -D front door + tun2proxy
path), (3) standalone SOCKS client wrapper for quinn/noq that must
work with any RFC 1928 server (iroh relay/peer IP-leak motivation,
alknet ADR-090 generalized); the earlier docs conflated the
consumer-side bind with the producer-side local backend
- principle 6: the vpn-like endgame — tunnel a produced SOCKS5
resource to a local port, point tun2proxy (--proxy socks5://
natively) at it; verified tun2proxy src/args.rs
- OQ-SK-04 resolved as fork-first: 'fork' = vendor-and-vet inline in
the crate (minimal diff, feature-gate native-net), PR upstream as
courtesy, never wait on approval; wasm-drop (alkhttp precedent) is
the escape hatch, not the plan
- AGENTS.md conventions 4/9/17 aligned (fork-first, binds on either
side, wasm posture)
- OQ-SK-03: RFC 1928 control/data never interleave (fast-socks5
wait_on_tcp treats post-reply control bytes as garbage), so the
alktty 5-stream demux solves a problem SOCKS5 doesn't have; phase
model (pass-through CONNECT, len-prefixed datagrams post-reply)
subsumes it; the demux's real advantage is an additive in-band
stream-type vocabulary — noted as the honest one-way-door fork
- OQ-SK-04: no structural fork needed for the channels surface
(router.rs interception shape covers CONNECT; run_udp_proxy_custom
+ reply_success + the pure UDP codec cover ASSOCIATE); the
fork/wrap/reimplement decision is driven entirely by the wasm
feature-gating outcome; full fork documented as least attractive
glm-5.3-flash