Routing on Skycoin Blog

Programmable Routing Policy: Skylark and WASM

Thu, 04 Jun 2026 00:00:00 +0000

Skywire’s router has, over the last month, become genuinely capable. It builds multihop routes through chosen intermediates, fans a flow across multiplexed parallel routes, keeps those routes disjoint (no shared middle hop), routes the forward and reverse legs asymmetrically, and ranks candidates by measured per-hop latency. That’s a rich mechanism.

But a mechanism needs a policy. Which of those capabilities applies to a given flow — how many routes, how many hops, through which countries, rotated how often — was, until recently, a decision hardwired in Go. If you wanted your VPN traffic to take a different path than your chat traffic, or to avoid transiting a particular jurisdiction, or to fan across four disjoint paths during the workday and collapse to one at night, you patched the router.

Route Setup Over Transports: The Source-Driven Cascade

Thu, 04 Jun 2026 00:00:00 +0000

To carry traffic across the skywire overlay, a multihop route has to be built: each visor along the path needs a routing rule telling it which transport to forward a packet onto next. Installing those rules has, until now, been the job of a route-setup node (RSN) — a dedicated service that, given a route, reaches out to every hop and writes the rule.

The way it reached each hop was the problem. The RSN dialed each visor over dmsg. And dmsg reachability is not the same thing as route reachability. A visor can be perfectly alive on its transports — its stcpr and sudph links up, forwarding packets fine — while its dmsg session has quietly gone half-dead (an older build with an undetected zombie session, a relay that dropped it). The RSN would try to dial that hop over dmsg, time out, and the whole route setup would fail — even though every transport the route actually needs is working.

Skywire Development Update — June 2, 2026

Tue, 02 Jun 2026 00:00:00 +0000

A routing-reliability day, and two releases. The router gets a run of hardening — one hop’s failure no longer tears down the whole route, a cluster of panics and races are guarded, and a multiplexed-route stall is fixed. The dmsg-first client stops a bad HTTP fallback, the hypervisor starts forwarding browser-side UI errors into the visor log (where they’re actually visible), and v1.3.62 / v1.3.63 ship.

Skywire: Router — Don’t Let One Hop Sink the Route

2976 fix(router): stop one hop’s failure from RST-ing the whole route (setup cascade) — during route setup, a single hop failing could cascade into a reset of the entire route. Now a hop failure is contained, so the rest of the route survives and can be repaired rather than torn down wholesale. This is the kind of fix that turns “the route flaps when any intermediate hiccups” into “the route tolerates a hiccup.”

Skywire Development Update — May 31, 2026

Sun, 31 May 2026 00:00:00 +0000

A short day, mostly routing-policy ergonomics: the policy’s rotation callbacks get richer inputs, and the proxy and VPN clients learn to take a --routing-policy directly on the command line.

Skywire: Routing Policy — Richer Rotation, CLI Wiring

2938 feat(router/policy): expose leg byte counters and hop chain to rotation callbacks — a policy’s rotation callback now receives the per-leg byte counters and the hop chain. A rotation policy can make decisions on real data — “this leg has moved very little traffic” or “this path runs through an intermediate I want to avoid” — rather than rotating blindly on a timer.

Skywire Development Update — May 29, 2026

Fri, 29 May 2026 00:00:00 +0000

The routing-policy work keeps building. Yesterday’s Starlark policies gain a WASM backend (a compiled, language-agnostic alternative to the Starlark interpreter), the operator-facing name “skylark”, periodic route rotation, a hypervisor-UI panel to manage it, and runtime per-app hot-swap. Underneath, the router’s mux loop gets a best-effort + local-fallback path, and the CXO node sheds a long-standing accept-path serialization bottleneck. Two releases, v1.3.60 and v1.3.61, go out.

Skywire: Routing Policy — WASM Backend, Rotation, and “Skylark”

2913 feat(router/policy): WASM backend for routing policies — alongside the Starlark interpreter, policies can be compiled to WASM and run through a WASM backend. Starlark is the readable, write-it-inline option; WASM is the compile-it-from-any-language, run-it-fast option. The router can evaluate either.

Skywire Development Update — May 28, 2026

Thu, 28 May 2026 00:00:00 +0000

The headline feature of the week lands: operator-programmable routing policy. Skywire’s router already does multihop, multiplexed, latency-ranked, asymmetric path selection — but which path a given flow takes was hardwired in Go. Today that decision becomes a program the operator writes, in Starlark (a small, sandboxed, Python-like language), evaluated per dial. A flow can be steered onto disjoint paths, pinned by 5-tuple, made latency-adaptive, prioritized by DSCP, or forced onto the overlay — by policy, not by patch.