Commit Graph
4 Commits
Author SHA1 Message Date
glm-5.3-flash a628715106 docs: OQ-SK-04 restructured as the conditional decision tree it is
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.
2026-09-12 11:00:56 +00:00
glm-5.3-flash 766e489f99 docs: three-component split; fork-first (vendor-and-vet) posture; consumer-side bind
- 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)
2026-09-12 10:21:29 +00:00
glm-5.3-flash 216a5e965e docs: phase-0 — UDP phase model vs alktty-style demux; fork-vs-reimplement collapses onto OQ-SK-04
- 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
2026-09-12 09:46:05 +00:00
glm-5.3-flash 4c641ea9c0 docs: repo init — gitignore, AGENTS.md, Phase 0 draft
- .gitignore (target/, node_modules/, .worktrees/, Cargo.lock)
- AGENTS.md: project conventions adapted from alktunnels for the
  SOCKS5 wrapper crate (no-forced-binding posture, fast-socks5
  genericity, producer/consumer vocabulary, upstream-asks rule,
  verification commands with the wasm caveat for OQ-SK-04)
- docs/research/phase-0.md: Phase 0 draft — vision, prior art
  (fast-socks5 surface, alktunnels -D conclusion, alknet ADR-090
  client, noq trait-shape divergence), open questions OQ-SK-01..07,
  POC candidates, convergence checklist
- sdd_process.md: package name fixed (alkcall -> alksocks)
2026-09-12 09:19:54 +00:00