glm-5.3-flash
4730672f10
- endgame story makes both mechanisms real: consumer binds the produced SOCKS5 resource locally (optional front door, ssh -D shape without the forced bind) and points tun2proxy at it - producer side: identity seam only (CF-005/CF-006); a password there is moot against the ACL system — in-band conversation runs NoAuth - consumer front door: owns RFC 1929 where vanilla clients need it (tun2proxy/curl user:pass), maps accepted credentials to the channel identity it opens the producer with; the SOCKS password never crosses the channel as a SOCKS password - replace-or-second-gate sub-question dissolves: the mechanisms occupy different planes (door-local creds vs channel-level identity) - remaining for Phase 1: credential->identity mapping shape; producer- side local backend door surface; AuthMethod trait vs door-owned check