Skywire Development Update — October 11, 2026

The eleventh of October introduced the host bridge, a small helper process that lends a visor running in a browser tab the sockets of the computer it runs on, and within the same day the browser visor was using it to run stcpr and sudph transports at an address of its own, to forward host ports to its own apps, and to remember all of it across restarts. Reward pool 2 moved to paying on bandwidth that both ends of a transport agree on, and the first three parts of verifying that bandwidth by the content of the byte stream itself went in, along with a fix for restarts of transport discovery crediting a transport’s whole lifetime again. The deployment status page gained per-type columns and version information, and a large batch of fixes for Skywire Mobile landed ahead of its next release, including a mail screen for Skymail, search and blocking in SkyChat, and calls that are no longer silent when answered on a locked phone.

Skywire: A Host Bridge for the Browser Visor

A visor in a browser tab cannot listen on a port or open a raw socket, so it only ever gets the transports it dials out itself, and its proxy and VPN clients cannot serve the host they run on. 5600 added the host bridge to close that gap. It is a small process on the same machine that the tab reaches over a WebSocket on loopback, and each stream on that connection asks the bridge to dial TCP, listen on TCP or bind UDP, with the tab end handing back ordinary network types backed by the host’s real sockets. The bridge refuses any host other than loopback and any origin outside its list, requires a random token printed at start, and holds no keys. It runs as skywire hostbridge or as its own small binary, which built with TinyGo comes to about 700 KiB.

5605 let a browser visor connect to a bridge with cli visor hostbridge connect and forward ports on the bridge’s host to addresses the visor can dial, for example a local port on the host to the tab’s own SOCKS client, redialing with backoff when the session ends and reopening its forwards. 5609 made the visor save the bridge’s address and forwards in its config so it reconnects on its own after a restart, and made the bridge keep its token in a file so its address stays the same across runs; a new test now fails whenever the config gains a field its JSON mirror lacks, after the new section was found being dropped on every load.

5610 routed the stcp, stcpr, sudph and QUIC carriers and the unified transport port through one socket interface, which on a native visor is simply the operating system. 5615 then used it to run stcpr and sudph for a browser visor on the bridge’s host. In a desk tab behind a home NAT, the address resolver recorded the tab’s stcpr and sudph at the host’s public address, autoconnect opened twenty-three stcpr transports out, and five visors on the internet opened sudph transports in. Inbound stcpr still needs a forwarded port, as it does for a native visor behind NAT, and was not tested from outside.

5616 embedded TinyGo builds of the bridge for Linux, macOS and Windows, about 750 KiB each, in the browser build, with a dashboard page that offers the right build for the user’s computer, shows the command to run, and connects the visor to the address the bridge prints; a guide covers the whole feature. Testing with those builds found the carriers spinning through ports when a listen failed for reasons other than the port being taken, which now waits a second instead. 5617 paired each bridge with a single visor through a secret it hands out on first connect, which later sessions prove with a challenge response, and made the desk page itself open the bridge’s WebSocket first, since a dedicated worker cannot be relied on to raise the browser’s local network access prompt. 5618 gave apps a host: address prefix that names a port on the computer in both builds, the operating system natively and the bridge in a tab, so the same app config means the same port either way.

Skywire: Paying Pool 2 on Bandwidth Both Ends Agree On

5608 changed reward pool 2 to pay each edge of a transport the smaller of what it sent and what the other edge says it received, and to pay nothing on a transport only one edge reported, restoring a cap that had been removed in June now that both edges report on ninety to ninety-seven percent of transports. Transport discovery’s settled day now counts unverified transports, and the bandwidth collector and cli tp metrics share one implementation of the rule.

5604 fixed transport discovery crediting a transport’s entire lifetime again after every restart. It credits the change in each reporter’s cumulative counters since its last snapshot, which it kept for ten minutes, and each restart, now part of every host visor update, outlasted that; a visor up for two days was credited 126 GB in one day against 26 GB on its own counters. The snapshot now lives six hours. 5602 kept an expired transport’s type alongside its bandwidth, which had been showing under a blank type on the status page.

The next three changes began verifying bandwidth by content rather than by counters alone. 5611 has each transport hash the bytes it sends and receives on its current connection and keep checkpoints at fixed offsets, so matching checkpoints from the two ends prove those bytes passed between them. 5612 published those checkpoints over the existing telemetry feed, and 5613 kept more recent checkpoints and sampled them on wall-clock minute boundaries so both ends snapshot within seconds of each other. 5614 had transport discovery match them, crediting the furthest offset where both ends’ digests agree, and paying an edge on a comparable day at most its verified bytes plus a small allowance. Days without a comparable connection are paid on counters as before, so older visors and other transport types are unaffected.

Skywire: The Deployment Status Page

5601 revised the deployment status page with a column per transport type in the top-visors table, bare public keys in the services table, and process charts drawn once instead of by every embedded service. 5603 showed each listed key’s version where it is known, and had visors send their version in a header on service requests so each service can chart its traffic by caller version. 5606 fixed a regression from that change, where adding the header to a copied HTTP client lost the dmsg transport callers set on it afterwards and broke discovery lookups over dmsg; the header is now set per request. 5607 attributed requests that carry no version header by the caller’s key, using the versions transport discovery already knows, since only the newest visors send the header.

Skywire: Fixes for Skywire Mobile

5553 collected fixes and suggestions reported against Skywire Mobile v0.0.6, each checked on an Android emulator against a desktop visor unless noted. A report of voice and video messages that stopped responding could not be traced to a proven cause, so three ways a recording could stick for the life of the page were closed, along with a permission request Android takes without showing a dialog and a broken saved conversation that left every button dead; the reporter still needs to retest on their phone. The diagnostics export now includes the chat page’s log, the WebView version, Android’s record of how the app’s recent processes ended, and any crash stack. Calls answered while the phone was locked had been silenced by Android, because the call service started only after the other side answered; it now starts when the call is placed. The visor config is regenerated once after each install or update, with the old config restored if that fails or would change the key.

The same change added a mail screen for Skymail, mail between visors over the Skywire network, with inbox, sent, attachments, replies, allowed senders and notifications, marked beta since delivery is still immediate with no queue. SkyChat gained search over contacts, groups, channels and messages, a block list, and an optional setting that holds strangers’ messages as requests until accepted, and looking up a new contact’s published name and picture now asks over skynet and dmsg at once. Notifications follow the app language, and tapping a chat notification opens its conversation. 5598 prepared the F-Droid release of 0.0.7, removing the one prebuilt file added since the last release, which the mobile build does not use, so the source scanner passes, and adding the changelog and an updated description.

Skywire: Three Red CI Lanes

5599 fixed three failing CI lanes. The VPN end-to-end test had failed on almost every run for three days because a transport added right after a peer restarted was answered from caches that outlived the restart; transports added by hand through the CLI or the hypervisor now ask the address resolver directly, while automatic dials keep the caches. A stream benchmark had failed about half its runs since the previous day’s yamux change, because coalescing frames shifted which frames the test’s simulated loss hit, and the delay it measured came from recovering a lost tail frame rather than from the cut it was meant to measure; its links are now lossless. A Windows cache test that needed two calls inside 100 ms now takes its time from a replaceable clock instead of sleeping.