feat(transport): visor accepts WebTransport + registers its cert hash with the AR#3303
Merged
Merged
Conversation
… with the AR Second PR of the WT carrier build. Every native visor now starts a WebTransport server and advertises it so browser (wasm) visors — which can only reach a visor over WS/WT/WebRTC — can dial it: - initWTClient (module "wt", depends on the transport module like ws/quic) calls InitClient(types.WT). The WT server binds its own ephemeral UDP port, generates a self-signed cert, and serves HTTP/3 WebTransport. - The WT client gets the AR (held as `any`, mirroring wsClient.ar). On serve it registers the endpoint + the cert's SHA-256 hash via BindWT (skycoin#3302) and keeps the entry alive with a 90s re-register (retry-with-backoff like stcpr/quic). wtClient.Dial already guards a nil table (no crash on `tp add -t wt` before the dial-resolution PR lands). Verified live: the WT server starts, binds UDP, mints a cert, and BindWT retries (404 until the AR redeploys skycoin#3302); visor stays alive. Next: dial-side resolution (resolve the peer's WT endpoint+hash from the AR and pin) + WS/WT multi-type autoconnect.
0pcom
added a commit
that referenced
this pull request
Jun 26, 2026
…h via the AR (#3304) Third PR of the WT carrier build. A native `tp add -t wt <pk>` (and the dial side generally) had only the WTTable to find a peer's WebTransport endpoint, so a native visor returned ErrWTEntryNotFound. Now, on a table miss, wtClient.Dial resolves the peer's WT record from the address resolver — the endpoint (https://host:port/skywire) AND the pinned self-signed cert hash that BindWT (#3302/#3303) stored — and dials with the pin. Mirrors the native WS resolution. Build-tagged like the WS resolver (real on !tinygo via addrresolver, no-op stub on tinygo); browser build unaffected (table hit first, nil AR). End-to-end native↔native WT needs #3302 (AR) + #3303 (accept) deployed so peers have WT records; this is the dial half.
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
… with the AR (#3303) Second PR of the WT carrier build. Every native visor now starts a WebTransport server and advertises it so browser (wasm) visors — which can only reach a visor over WS/WT/WebRTC — can dial it: - initWTClient (module "wt", depends on the transport module like ws/quic) calls InitClient(types.WT). The WT server binds its own ephemeral UDP port, generates a self-signed cert, and serves HTTP/3 WebTransport. - The WT client gets the AR (held as `any`, mirroring wsClient.ar). On serve it registers the endpoint + the cert's SHA-256 hash via BindWT (#3302) and keeps the entry alive with a 90s re-register (retry-with-backoff like stcpr/quic). wtClient.Dial already guards a nil table (no crash on `tp add -t wt` before the dial-resolution PR lands). Verified live: the WT server starts, binds UDP, mints a cert, and BindWT retries (404 until the AR redeploys #3302); visor stays alive. Next: dial-side resolution (resolve the peer's WT endpoint+hash from the AR and pin) + WS/WT multi-type autoconnect.
0pcom
added a commit
that referenced
this pull request
Jul 7, 2026
…h via the AR (#3304) Third PR of the WT carrier build. A native `tp add -t wt <pk>` (and the dial side generally) had only the WTTable to find a peer's WebTransport endpoint, so a native visor returned ErrWTEntryNotFound. Now, on a table miss, wtClient.Dial resolves the peer's WT record from the address resolver — the endpoint (https://host:port/skywire) AND the pinned self-signed cert hash that BindWT (#3302/#3303) stored — and dials with the pin. Mirrors the native WS resolution. Build-tagged like the WS resolver (real on !tinygo via addrresolver, no-op stub on tinygo); browser build unaffected (table hit first, nil AR). End-to-end native↔native WT needs #3302 (AR) + #3303 (accept) deployed so peers have WT records; this is the dial half.
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.
Second PR of the WebTransport carrier build (after #3302, the AR cert-hash foundation).
Every native visor now starts a WebTransport server and advertises it so browser (wasm) visors — which can only reach a visor over WS/WT/WebRTC — can dial it:
initWTClient(modulewt, depends on the transport module like ws/quic) callsInitClient(types.WT). The WT server binds its own ephemeral UDP port, generates a self-signed cert, and serves HTTP/3 WebTransport.any, mirroringwsClient.ar). On serve it registers the endpoint + the cert's SHA-256 hash viaBindWT(feat(address-resolver): WebTransport bind/resolve with cert-hash (WT discovery foundation) #3302) and keeps the entry alive with a 90s re-register (retry-with-backoff like stcpr/quic).wtClient.Dialalready guards a nil table, so notp add -t wtcrash before the dial-resolution PR lands.Verified live
The WT server starts, binds UDP (port 7777), mints a cert (
74d836a3…), andBindWTretries — 404 until the AR redeploys #3302 — visor stays alive throughout.Next PRs: dial-side resolution (resolve the peer's WT endpoint+hash from the AR, pin the cert) → WS/WT multi-type autoconnect.
🤖 Generated with Claude Code