feat(transport,dmsg): browser-native WT dial for the std-Go wasm visor (build-tag fix)#3305
Merged
Merged
Conversation
…r (build-tag fix) The browser WebTransport dial (DialWebTransportJS, a syscall/js adapter) and the transport-layer wt_browser.go that calls it were gated `tinygo && js && wasm`, so the STD-Go js/wasm visor compiled the native wt_native.go path instead — webtransport-go/quic-go, which can't open UDP in a browser. So a std-Go wasm visor could never dial WT. (WS got away with the analogous gate because coder/websocket has a real js implementation; quic-go does not.) Retag by browser-vs-native, not tinygo-vs-native — the real distinction: - transport/network: wt_native.go !tinygo → `!tinygo && !(js && wasm)` (native only); wt_browser.go `tinygo && js && wasm` → `js && wasm` (any browser) and it now also provides the Start + resolveWTViaAR stubs a browser needs (can't serve, no AR); wt_tinygo.go `tinygo` → `tinygo && !(js && wasm)` (embedded only) so it doesn't collide with wt_browser on tinygo-wasm. - dmsg: wt.go !tinygo → `!tinygo && !(js && wasm)`; wt_js_tinygo.go `tinygo && js && wasm` → `js && wasm`. The shared wsAddr/wsTimeoutError helpers move to a new jsaddr_js.go (`js && wasm`) so both the WS (tinygo-only) and WT (all-js) browser adapters get them. The dmsg WS session dial is untouched (coder/websocket, ws.go) — the wasm visor's lifeline is unaffected. Builds verified: native, std-Go js/wasm (cmd/wasm-visor). Symbol-consistent for tinygo-wasm + tinygo-embedded (helpers moved to a file both include; no new redeclarations). Enabling change — the wasm autoconnect dialing WT is the next PR.
0pcom
added a commit
that referenced
this pull request
Jun 26, 2026
…lic visor (#3306) A native visor makes BOTH stcpr and sudph to the same public visors (autoconnect.go) for redundancy + path diversity. The browser analog is WS (TCP) + WT (QUIC); until now the wasm autoconnect dialed only WS. The autoconnect now dials both carriers to each public visor: - WS rides the stcpr cmux port (resolve stcpr IP, ws://ip:port/) — unchanged. - WT: new arDmsg.resolveWT fetches the peer's AR WT record (/resolve/wt) — the https://host:port/skywire endpoint + the pinned self-signed cert hash (stored by BindWT) — sets the wtTable entry and SaveTransport(WT). Needs the browser-native WT dial (#3305) and the AR WT records (#3302/#3303 deployed). Counts DISTINCT visors now (a peer may hold both a WS and a WT transport), and a peer with no WT record (404) just gets WS — graceful until the fleet registers WT. Refreshes the committed wasm blob.
0pcom
added a commit
that referenced
this pull request
Jul 7, 2026
…r (build-tag fix) (#3305) The browser WebTransport dial (DialWebTransportJS, a syscall/js adapter) and the transport-layer wt_browser.go that calls it were gated `tinygo && js && wasm`, so the STD-Go js/wasm visor compiled the native wt_native.go path instead — webtransport-go/quic-go, which can't open UDP in a browser. So a std-Go wasm visor could never dial WT. (WS got away with the analogous gate because coder/websocket has a real js implementation; quic-go does not.) Retag by browser-vs-native, not tinygo-vs-native — the real distinction: - transport/network: wt_native.go !tinygo → `!tinygo && !(js && wasm)` (native only); wt_browser.go `tinygo && js && wasm` → `js && wasm` (any browser) and it now also provides the Start + resolveWTViaAR stubs a browser needs (can't serve, no AR); wt_tinygo.go `tinygo` → `tinygo && !(js && wasm)` (embedded only) so it doesn't collide with wt_browser on tinygo-wasm. - dmsg: wt.go !tinygo → `!tinygo && !(js && wasm)`; wt_js_tinygo.go `tinygo && js && wasm` → `js && wasm`. The shared wsAddr/wsTimeoutError helpers move to a new jsaddr_js.go (`js && wasm`) so both the WS (tinygo-only) and WT (all-js) browser adapters get them. The dmsg WS session dial is untouched (coder/websocket, ws.go) — the wasm visor's lifeline is unaffected. Builds verified: native, std-Go js/wasm (cmd/wasm-visor). Symbol-consistent for tinygo-wasm + tinygo-embedded (helpers moved to a file both include; no new redeclarations). Enabling change — the wasm autoconnect dialing WT is the next PR.
0pcom
added a commit
that referenced
this pull request
Jul 7, 2026
…lic visor (#3306) A native visor makes BOTH stcpr and sudph to the same public visors (autoconnect.go) for redundancy + path diversity. The browser analog is WS (TCP) + WT (QUIC); until now the wasm autoconnect dialed only WS. The autoconnect now dials both carriers to each public visor: - WS rides the stcpr cmux port (resolve stcpr IP, ws://ip:port/) — unchanged. - WT: new arDmsg.resolveWT fetches the peer's AR WT record (/resolve/wt) — the https://host:port/skywire endpoint + the pinned self-signed cert hash (stored by BindWT) — sets the wtTable entry and SaveTransport(WT). Needs the browser-native WT dial (#3305) and the AR WT records (#3302/#3303 deployed). Counts DISTINCT visors now (a peer may hold both a WS and a WT transport), and a peer with no WT record (404) just gets WS — graceful until the fleet registers WT. Refreshes the committed wasm blob.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Part of the WebTransport carrier build — the wasm dial side.
DialWebTransportJS(the syscall/js WebTransport adapter) and the transport-layerwt_browser.gothat calls it were gatedtinygo && js && wasm, so the std-Go js/wasm visor compiledwt_native.goinstead — webtransport-go/quic-go, which can't open UDP in a browser. So a std-Go wasm visor could never dial WT. (WS avoided this because coder/websocket has a real js implementation; quic-go does not.)Retag by browser-vs-native (the real distinction)
transport/network:
wt_native.go!tinygo→!tinygo && !(js && wasm)(native only)wt_browser.gotinygo && js && wasm→js && wasm(any browser) + now provides theStart+resolveWTViaARstubs a browser needs (can't serve, no AR)wt_tinygo.gotinygo→tinygo && !(js && wasm)(embedded only) so it doesn't collide withwt_browseron tinygo-wasmdmsg:
wt.go!tinygo→!tinygo && !(js && wasm);wt_js_tinygo.gotinygo && js && wasm→js && wasmwsAddr/wsTimeoutErrormove to a newjsaddr_js.go(js && wasm) so both the WS (tinygo-only) and WT (all-js) browser adapters get themws.go) — the wasm visor's lifeline is unaffectedVerified
Native + std-Go js/wasm (
cmd/wasm-visor) build clean. Symbol-consistent for tinygo-wasm + tinygo-embedded (helpers moved to a file both include; no new redeclarations; the tinygonet/http roundtrip_jserror is pre-existing, unrelated).Enabling change — the wasm autoconnect dialing WT (multi-type) is the next PR.
🤖 Generated with Claude Code