Development on Skycoin Blog

Skywire Development Update — September 5, 2026

Sat, 05 Sep 2026 00:00:00 +0000

The day’s through-line ran from a bare continue statement to a visor’s reward eligibility. Three readers in the transport discovery skipped a failed batch silently, and because those counts decide online status and uptime feeds the reward threshold, a short read could push live visors under the bar while still returning a plausible number. Fixing that fed a larger rebuild of the reward server’s statistics pages, which moved off HTTP-over-dmsg onto CXO feeds and gained panels for the dmsg substrate, service reachability, transports per visor, and the route setup nodes that negotiate every route in the network and had never appeared on any chart.

Skywire Development Update — September 4, 2026

Fri, 04 Sep 2026 00:00:00 +0000

The desk stopped being a page the hypervisor happened to serve and became the hypervisor UI itself — on the visor-attached hypervisor, on the standalone hv serve, and on the documentation site, whose root now greets with a terminal that has just run skywire --help. The docs moved into the binary that documents them, so the command reference is the cobra tree walked live on every request rather than a copy that can drift, and it renders with no visor running at all. Underneath the surface work, the transport discovery’s per-transport metrics feed — the only dead feed on the deployment — was traced to a single object a fraction over CXO’s 16MB limit, which is refused at Put time and therefore kills the whole feed rather than one window; it was gzipped, chunked, and rebuilt as immutable per-day leaves. A production dmsg server was found restarting roughly every eighty seconds, and the reward server’s statistics pages were found pulling 24MB over dmsg to compute three numbers TPD publishes in 138 bytes.

Skywire Development Update — September 3, 2026

Thu, 03 Sep 2026 00:00:00 +0000

Two threads ran through the day, and both were driven by measurement rather than by design. The wasm visor gained a real VPN client, with a gVisor userspace netstack standing in for the TUN device a browser tab cannot have. And a long run of skysocks and router fixes traced transfers that were spending two and three times the wire they needed: a 20MB upload torn down at twenty seconds by a write valve and again at 112 seconds by a keepalive that could not see uploads, a 20MB download putting 33.8MB of duplicate bytes on one leg against 14.7MB of payload. Alongside them the browser visor’s recurring five-hour death was root-caused to leaked peer connections, the resolving proxies gained status pages of their own, and the native hypervisor learned to serve the converged desk.

Skywire Development Update — September 2, 2026

Wed, 02 Sep 2026 00:00:00 +0000

The whole skywire binary runs in a browser tab now. Not a trimmed edge build — the full command tree, compiled to wasm, running skywire autoconfig in a terminal, booting a foreground visor that joins the P2P transport mesh, and serving its own hypervisor UI to a nested browser on the same page. By the end of the day that visor forms WebTransport transports like a native peer, renders the hypervisor UI natively through a service worker, and chains its proxies by default so any tab of the nested browser browses through the mesh. A try-it-now playground is live on the docs site at skycoin.github.io/skywire/playground.

Skywire Development Update — September 1, 2026

Tue, 01 Sep 2026 00:00:00 +0000

Four merges, each substantial: the retransmit storm that could eat a loaded mux stream is root-caused and fixed, dmsg servers become probeable per carrier — uncovering and fixing a silent QUIC downgrade along the way — five operations guides land in the docs, and the last modified in-tree dependency copies become proper forks.

Skywire: The Retransmit Storm, Root-Caused

Under sustained load, bufferbloat inflates the in-band RTT far past the loss-detection ceiling, so the 1.5s clamp declared every in-flight packet permanently lost — and because retransmitted entries were never re-stamped, every ~25ms SACK re-selected the same holes. Measured live: 93% of sent packets were retransmits, 50MB on the wire for 8.6MB of goodput, until liveness gave out. 4399 fixes both halves: retransmit entries carry their last send time and back off exponentially, and the RACK ceiling is floored at one measured RTT so the adaptive reorder window is never overridden by an absolute clamp.

Skywire Development Update — August 31, 2026

Mon, 31 Aug 2026 00:00:00 +0000

A hardening day for the browser visor: a page-freeze fix, an end to two CPU-pegging loops, and a local proxy-status page that answers even before the mesh does. A pair of allocation cuts round it out.

Skywire: The Browser Visor Behaves

4391 stops the standalone page stranding the visor on the page’s main thread, where any long computation froze the UI with it. 4393 ends the in-tab proxy pegging a core against zombie exits and makes the CLI-RPC bridge report honest liveness, and 4394 memoizes the local-route search, widens the proxy dial margin, and recovers a wedged shared-worker boot instead of leaving the tab stuck. 4396 gives the browser visor a local status.skysocks proxy-status page that is never gated by the interstitial — status must be readable precisely when routes are not up yet — and 4397 prefers proxy exits that are already direct transport peers, cutting the time to the first proxied page load.

Skywire Development Update — August 30, 2026

Sun, 30 Aug 2026 00:00:00 +0000

A performance campaign against the route finder, end to end: from per-request graph builds and path-copy storms down to landmark routing that composes far routes through the mesh’s natural hubs. Around it, range-splitting extends to HTTPS, routes gain a transport-type exclusion knob, and route calc learns to report how much disjoint capacity actually exists between two visors.

Skywire: The Route Finder Gets Fast

The route finder answered every source/destination pair with an exhaustive search over the dense transport graph, rebuilt per request. 4378 replaces path-copying with parent-pointer BFS, 4380 shares one background-refreshed route graph across requests, 4385 memoizes weighted route results per graph, and 4386 byte-sorts the search keys to kill string-conversion churn. 4390 caps the campaign with landmark routing: routes between every node and the highest-degree hubs are precomputed once per graph, and a far pair is answered by composing source-to-hub and hub-to-destination — with a shallow direct search keeping the optimal answer for near pairs and a full search as fallback, so nothing regresses. Composing via different hubs yields disjoint mux legs for free. On the visor side, 4382 builds local-route lookups once per discovery snapshot rather than per dial, and 4383 pins the transport feed so route calculation stops re-handshaking.

Skywire Development Update — August 29, 2026

Sat, 29 Aug 2026 00:00:00 +0000

The mux goes unidirectional: uploads and downloads no longer have to take the same paths. A dense day around that — the two ends of a route group learn to mirror each other’s leg state, two more schedulers and shared-bottleneck detection arrive, the proxy status page grows a two-level route tree and a GPU route graph, and the browser visor’s RPC becomes reachable over dmsg. A one-line hash fix at the end of the day unblocked the published development binary for 32-bit ARM.

Skywire Development Update — August 28, 2026

Fri, 28 Aug 2026 00:00:00 +0000

Forward error correction lands in the packet mux. Of the three named escapes from the in-order-stream wall, FEC is the first to ship: repair packets ride alongside data so a lost packet on one leg is reconstructed at the far end instead of stalling the reorder frontier until retransmit. Alongside it, retransmit timing itself gets modern — a RACK-derived threshold replaces the fixed timer — and the two ends of a route group start telling each other which legs are active.

Skywire Development Update — August 27, 2026

Thu, 27 Aug 2026 00:00:00 +0000

A day about the lifecycle of a mux leg. With per-frame noise aggregating a single stream across legs, the remaining failure modes are legs themselves misbehaving — black-holing, congesting, sitting in a different latency class, or living on the same LAN as their sibling — and today the router learned to admit, demote, replace and retire them deliberately. On top of that: a seamless in-flight route switch for proxy sessions, and a round of housekeeping from the SOCKS listener to the transport-discovery database.

Skywire Development Update — August 26, 2026

Wed, 26 Aug 2026 00:00:00 +0000

A day built around one idea, taken from RFC to on-by-default before it is out: per-frame noise for mux aggregation. Rather than striping a route group’s single noise-encrypted byte stream across legs and reordering it back together on the far side, noise is applied per frame, so each frame decrypts on its own and legs aggregate a single stream with no cross-leg reordering at all — the root of the reorder-buffer hazards the data-plane fixes have been chasing. Around it: a routing lock fix, the visor-state fields to actually watch the new path work, and a cluster of CI and skysocks housekeeping. The afternoon kept building on the new path: warm-standby aux legs, live mux control, the no-skip reorder rule that ends a stream-corruption class, and a predictive scheduler.

Skywire Development Update — August 25, 2026

Tue, 25 Aug 2026 00:00:00 +0000

The throughput day. A single-line change — raising the yamux stream window from 256 KB to 16 MB for the mesh’s bandwidth-delay product — turns out to be the throughput fix the mux work had been circling: the mesh was window-starved, not CPU- or mux-bound. It lands next to a multi-tunnel aggregation foundation, an adaptive mux that finally converges to the fastest legs in one tick, sharded CXO feeds that let a busy hub’s Root fill, and a large package reorganization grouping the deployment services under pkg/deployment.

Skywire Development Update — August 24, 2026

Mon, 24 Aug 2026 00:00:00 +0000

Today’s thread is the transport-discovery feed getting its own dedicated CXO channel so TPD can fill it completely, with a subscriber allowlist gating the service-consumed feeds and the aggregator’s node identity bound to TPD’s key so gated visors accept it. A survey-key mismatch that had been costing operators their rewards is fixed, the proxy status page gains a bilateral route-group tree with a matching proxy tree CLI, and an interactive console over the command tree lands.

Skywire Development Update — August 23, 2026

Sun, 23 Aug 2026 00:00:00 +0000

The proxy status page becomes a live instrument today: it pushes updates over a WebSocket control channel and SSE instead of a full-page refresh, folds the per-leg mux table and full routes into one route tree, and stays reachable even when the exit is down. Underneath it a mux aux-leg race (issue #80) is buffered, another CXO publisher freeze — this one from a batch-rollback cache desync — is cured, and an optional in-process dmsg server that shares the visor key lands, default off.

Skywire Development Update — August 22, 2026

Sat, 22 Aug 2026 00:00:00 +0000

The busiest day of the run, on two fronts. A CXO publisher-freeze is diagnosed and closed from several angles — the publisher stops publishing stale history, hydrates best-effort around dangling references, and surfaces its own feed health in visor state. And the adaptive router gets a composite destination-transport oracle, capacity-weighted distribution, and a set of guardrails that keep it from reusing a transport already in the group or fighting an explicit --direct flag. The proxy status page grows a full per-leg route with every hop and PK.

Skywire Development Update — August 21, 2026

Fri, 21 Aug 2026 00:00:00 +0000

A large CLI-standardization sweep runs across almost every command group today, fixing small bugs and converging the flag and help vocabulary, and it lands next to a set of route-setup reliability fixes that stop intermittent skynet route drops and apps stuck in “starting”. The proxy status surface gains a real HTTPS certificate and a chunked live route-setup progress stream, and a route-visualizer scaffold goes in.

Skywire: Route Setup Stops Dropping

4078 sets up candidate route groups in parallel rather than serially, fixing a steady-connection stall where a slow candidate delayed the whole dial. 4057 retransmits the route-group setup handshake to prevent intermittent skynet route drops, and 4051 stops a route-setup drop from wedging an app in the “starting” state, adding a cascade→classic fallback so a failed cascade setup degrades to the classic path instead of hanging. 4081 excludes same-LAN peers as routing intermediates for genuine route diversity, and 4079 has the adaptive default hold a warm standby with an asymmetric forward/reverse shape, app-agnostically.

Skywire Development Update — August 20, 2026

Thu, 20 Aug 2026 00:00:00 +0000

The routing-policy work crosses a threshold today: adaptive becomes the default preset, and a family of conditional presets and a native-Go engine let it run on the TinyGo wasm-visor without a WASM interpreter aboard. Alongside it the CXO treestore gains real self-heal so a publisher can no longer freeze on an evicted object, the mux data plane gets a no-dip hot-swap and a full-window SACK, and the CLI gains a live per-leg mux chart and a one-call visor state snapshot. The packaging side moves to a rolling per-merge binary and drops the retired stable channel.

Skywire Development Update — August 19, 2026

Wed, 19 Aug 2026 00:00:00 +0000

The big thread today is a root-cause fix to transport discovery: the transport-discovery service had been reflecting only about 9% of the real transport graph, and the route-finder plans over that view, so it was blind to most of the network. A run of eight fixes traces it to CXO fills breaking over short-lived announce connections and closes the gap from both ends — the publisher makes its feed fill faster and smaller, the aggregator keeps a stable source, and both sides now verify what they publish. Alongside it, an optional route-calculation path sidesteps the discovery service entirely, the mux data plane gets two more fixes, and the performance presets move onto the no-dip engine.

Skywire Development Update — August 18, 2026

Tue, 18 Aug 2026 00:00:00 +0000

Two campaigns reach their point today. Route ranking stops guessing at transport quality by type and starts using measured throughput and end-to-end latency, in a three-phase build that goes from free passive observation to an active packet-pair probe to ranking that treats the type cost as a mere prior. And the warm-standby mux primitive — a leg that stays alive but parked — lands and is wired through the policy ABI, so rotating-bw rotates by promoting a warm standby instead of tearing a live leg down mid-stream. Alongside them, an app can finally override the visor-global mux defaults, and the deployment HTTP and CXO surfaces are gzipped.

Skywire Development Update — August 17, 2026

Mon, 17 Aug 2026 00:00:00 +0000

A large day on the multiplexed data plane. A multi-leg mux route group had been establishing cleanly but carrying no aggregated data — mux=1 was fine, adding a healthy second leg black-holed the transfer to zero bytes — and today three localized bugs behind that are found and fixed, so a mux>1 group finally aggregates. In parallel the routing-policy engine gets its compiled WASM presets embedded and dispatched from one bundle with several new dynamic presets, the native mesh proxies gain a branded route-building interstitial, and the code graph is published as a page on the site.

Skywire Development Update — August 16, 2026

Sun, 16 Aug 2026 00:00:00 +0000

A focused day on the browser visor and the vendored forks behind it. The wasm-visor tour gains a real file browser and a set of hardening fixes, its HV-UI caches are pre-warmed at boot so the first visit is instant, the bundled wallet surface is corrected on two fronts, and the hand-copied 0magnet module sources are dropped in favor of importing the forks by their own paths.

Skywire: The 0magnet Forks, Imported Not Copied

3951 removes the hand-vendored copies under third_party/0magnet and requires the modules by their own paths. The copies were staging — sources vendored by hand so the browser-terminal work could move without a round trip through another repository — and that trade had stopped paying: they had already fallen behind, xterm-go and websh having gained a ResizeObserver that re-fits the terminal to its container rather than the window, which is exactly what the hypervisor UI needs, since its terminal lives inside a WinBox window. No replace directives are needed — each fork is a module in its own right and resolves normally — and only four files outside the copied trees imported them, none reaching into an internal/ package, so the rewrite is a straight path substitution that also picks up an afero fix narrowing the TinyGo shims to js/wasm where they belong.

Skywire Development Update — August 15, 2026

Sat, 15 Aug 2026 00:00:00 +0000

Most of today is the browser visor becoming trustworthy to use: the hypervisor-UI tabs that spun forever now render at once, clearnet and mesh browsing stop failing on transient races, and a POST-body corruption that had been silently rewriting every request body is fixed. Underneath it the transport layer sheds two sources of wasted goroutines and one half-open leak, the CXO subscription goes live instead of polling, and the CLI gains two output filters that work on both binaries.

Skywire Development Update — August 14, 2026

Fri, 14 Aug 2026 00:00:00 +0000

A broad day of hardening under two headings: the network visualizer moves onto a WebGL renderer that is a role of the single wasm-visor blob rather than a second binary, and a run of correctness fixes — a runtime CPU peg in the browser visor, the browse-origin routing finally under test, and a lint-and-format sweep that unblocks every open PR. Alongside them the routing-policy library rounds out with three new presets and the vendored forks are synced back to their upstreams.

Skywire Development Update — August 13, 2026

Thu, 13 Aug 2026 00:00:00 +0000

Two threads today, both about a program describing itself honestly to whatever reads it. The larger is the foundation for structured CLI output: skywire cli learns to emit --help --json — a machine-readable schema of all 379 commands — and its output helper is replaced by a printer that renders one self-describing value rather than a JSON blob and a hand-written human string that had already drifted apart. In the same pass the transport command’s output shape, which existed as three copies that disagreed, is consolidated into one importable type the e2e suite shares. Alongside it, a release-hygiene fix on the mobile side stops the visor’s version being stamped from the wrong tag.

One Toolchain, Two Repositories: A Cross-Repo Front-End Modernization

Wed, 12 Aug 2026 00:00:00 +0000

Over the past two weeks, every Angular front-end in the Skycoin and Skywire ecosystem was pulled onto one strict, modern build toolchain — the desktop wallet, the web wallet, the block explorer, and the Skywire hypervisor’s “manager” UI. It happened across two separate repositories, in the same window, converging on a single shared standard. This is the story of that convergence, because the interesting part isn’t any one upgrade — it’s that four independently-maintained UIs ended up governed by the same rules on purpose.

Skywire Development Update — August 12, 2026

Wed, 12 Aug 2026 00:00:00 +0000

A very large day, on two fronts that rarely land together. The manager UI — the Angular hypervisor front-end — was brought to the same engineering footing as skycoin’s three other front-ends in a single coordinated stack: explicit change detection, strict TypeScript with strict templates, correctness-matched ESLint, the esbuild application builder, Angular 22, and a browser smoke check that catches the class of migration bugs a build and a lint and a spec all miss. In parallel the cascade route-setup verification campaign gained the observability and the leg-level reclamation it needs to prove its own correctness, dmsg carrier selection learned to converge and self-heal, and the CLI got several honesty fixes. Underneath it all, the manager UI was also made null-safe end to end. And on the Skycoin side the same wasm-cipher work reached its point: skycoin-lite now stamps both its Go and TinyGo artifacts, returns errors instead of trapping the whole module on a mistyped address, and — the payoff — was lifted out of a main into a Register any wasm program can call, so a skywire visor can carry the skycoin cipher, with a transport seam now under the wallet’s ApiService for the node API calls to follow.

Skywire Development Update — August 11, 2026

Tue, 11 Aug 2026 00:00:00 +0000

Today’s headline is a measured, fleet-wide efficiency win: a single quiet-feed keepalive that ends a churn pattern which had been re-handshaking healthy CXO connections every ninety seconds across the whole network — and, built on it, moving dmsg client-entry registration off its periodic HTTP-over-dmsg re-PUTs and onto a persistent CXO feed. Both attack the same cost: the Noise + post-quantum handshake that was dominating dmsg-discovery’s CPU. Alongside them the browser dmsg carrier finally converges from WebSocket to WebTransport, and the in-tab wasm visor grows a real shell. On the Skycoin side, the skycoin-web wallet’s unit-test suite came back from a single working spec to 1146 — reviving the golden-vector check that a browser-restored wallet holds the same coins as a node-restored one — the skycoin-lite wasm cipher stopped swallowing its own panics, and the cipher artifact learned to report the commit it was built from.

Skywire Development Update — August 10, 2026

Mon, 10 Aug 2026 00:00:00 +0000

Yesterday’s dmsg-bootstrap-floor RFC named the “real prize”: generalize the dmsg server’s peer-forwarding to any visor, carried over its own transports, so a visor need not stay attached to public dmsg servers once it has transports of its own. Today that primitive lands and gets wired into the two paths that make it carry real traffic — .skynet fetches and .dmsg reach — with a relay-discovery layer robust to a stale or empty transport graph. Alongside it, the real-origin mesh browser reaches its hosted form: mesh sites now open as genuine isolated web origins served entirely through the in-tab visor, behind a single wildcard TLS certificate. Skycoin had its second big day of the window: the front-end toolchain converged onto one shared ESLint base and aligned tsconfig strictness, all three Angular apps adopted OnPush change detection, the code moved to the @ngx-translate v18 API, and CI now builds, lints and tests every front-end. That shared-ESLint base is the standard skywire’s own manager UI was subsequently brought up to match.

Skywire Development Update — August 9, 2026

Sun, 09 Aug 2026 00:00:00 +0000

Today’s work lays the groundwork for a structural change in how the network uses dmsg. For most of Skywire’s life a visor stays permanently attached to a star of public dmsg servers, and the deployment services live behind those servers too — a topology that concentrates connection churn and handshake cost onto a handful of hosts. The design landing today reframes dmsg as a bootstrap-only floor: something a visor leans on to get its first transports, then increasingly bypasses by relaying for its peers over the transports it already has. Two of the four RFC components ship as running code — the idle-session reaper and always-on server relaying — alongside two empirical findings that decide how the deployment feeds eventually move off the dmsg-server star.

Skywire Development Update — August 8, 2026

Sat, 08 Aug 2026 00:00:00 +0000

Mostly reliability work under the hood. A silent first-session publish skip that kept a freshly-booted visor out of dmsg discovery — and blew the e2e suite’s time budget waiting for it — was tracked down and fixed. The CXO memory-growth and CPU-saturation seen on the live deployment hosts got three targeted fixes, paired with a server-side change that keeps the SD services feed always servable. On the UI side, the VPN client became a first-class in-place node tab and the clearnet iframe browser gained real reliability and browser parity.

Skywire Development Update — August 7, 2026

Fri, 07 Aug 2026 00:00:00 +0000

A lighter day, with one substantive CXO fix behind it. The blank network-uptime page and empty proxy/VPN server pickers on hypervisor visors were traced to a pair of CXO problems — a cold snapshot read before the first sync, and a per-feed dmsg-port collision — and both were fixed. The mobile SkyDEX screen was taught to follow the app’s theme instead of arriving as the one dark page in a light app, and the accumulated golangci-lint debt on develop was cleared so every open PR goes green again.

Skywire Development Update — August 6, 2026

Thu, 06 Aug 2026 00:00:00 +0000

Today the mobile app took center stage. The phone got a real Wallet — SKY, the fiber coins, BTC, and now native Ethereum with ERC-20 tokens and USDT built in — a redesign that gives every screen one visual language, and several passes of polish driven by using it on a device. Underneath, two periodic jobs the phone had been paying for got trimmed, and the phone stopped shipping the deployment’s survey whitelist it had no business carrying. On the browser side, the Services-Health tab is now populated and bounded on a wasm hypervisor, guarded against silent DTO drift; and a dmsg server can finally reach its own co-located transit client so its version stops showing blank.

Skywire Development Update — August 5, 2026

Wed, 05 Aug 2026 00:00:00 +0000

A heavy day across the whole stack. The dmsg server fleet learned to serve WebTransport on the socket it already listens on, so browser visors stop being stuck on the wss fallback. The decommissioned standalone Uptime Tracker was purged from every CLI command that still dialed its dead PK, with all uptime queries repointed to the TPD-integrated tracker over CXO. The native and browser edges kept converging — a shared transport-manager builder, a shared service-PK set, and a shared auto-transport policy that finally makes dmsg the genuine last resort on both. On top of that: discovery readouts that show real versions and inferred load, a guided tour that actually walks the UI, and a large mobile push — the phone’s Fleet window, SkyVPN over Android’s TUN, and a skychat that can move between devices. On the Skycoin repo the day was light: a batch of web-subproject dependency bumps and a README/security-policy pass that brings the project into line with skywire.

Skywire Development Update — August 4, 2026

Tue, 04 Aug 2026 00:00:00 +0000

The day’s most important change is a security fix in the shared httpauth middleware: over dmsg, the caller’s identity is now taken from the noise-verified session PK instead of an unverified header, closing an impersonation hole that let any dmsg peer spoof another visor to the address-resolver, transport discovery, service discovery, and the uptime tracker — and it reduces load while doing it. Alongside it, the hypervisor SPA’s long-planned GUI-embedding standardization landed in four steps (a SharedModule, a generic bundle-mount host, the first lazy-loaded feature module, and CDK-portal mounting that retires the self-iframe), the wasm-visor’s runtime-config reached parity with native and became editable, the clearnet browser got its search/nav/CSS working over the proxy, and the Android app grew SkyDEX, voice calls, and a shared address book.

The Header That Lied: Closing a Visor-Impersonation Hole

Tue, 04 Aug 2026 00:00:00 +0000

Every Skywire visor authenticates itself to the network’s core services — the address resolver, the transport discovery, the service discovery, the uptime tracker — with a small HTTP handshake carried by a shared httpauth middleware. Over the public internet that handshake does real cryptographic work: the caller sends its public key in a SW-Public header, a one-time SW-Nonce, and a secp256k1 signature proving it holds the private key for that public key. Forge the header and you fail the signature check. That is the whole point.

Skywire Development Update — August 3, 2026

Mon, 03 Aug 2026 00:00:00 +0000

A heavy day on the reward system: the survey-collection pipeline that had lived as host-only bash (fetch_surveys.sh + getlogs.sh) got ported into Go, made a drop-in for the live host, and paired with a new push model where a visor POSTs its own survey to the reward system over dmsg — closing the silent-drop gap where a demonstrably-up visor could earn nothing because a pull snapshot happened to read it offline. Around it: the systray decoupled from the visor process so a background service can be driven by an unprivileged tray, the pty-exec gate was narrowed to self-only so hypervisor control of remote visors works again by default, skynet source-routes got warm-route reuse, skychat gained a dmsg-first auto mode, and the network visualizer started counting every transport type it actually has.

Skywire Development Update — August 2, 2026

Sun, 02 Aug 2026 00:00:00 +0000

The headline today is a one-line divisor fix that retroactively repairs a fleet-wide reward regression: continuously-up visors that had been scoring ~30% daily uptime — below the 75% reward bar — snap back to ~100% the moment the reward server re-reads its stored counts, no fleet update required. Around it, apps got a way to reach a user who isn’t looking at them (a visor-global notification hub with an SSE stream, an OS-notify sink, and a hv notify bridge for headless nodes), a visor learned to quiesce itself without stopping the process, the wasm-visor’s clearnet proxy became a first-class configurable app, and skychat’s broadcast channels plus a mobile-app skeleton landed.

The Thirty-Percent Ceiling: A Reward-Uptime Divisor Bug

Sun, 02 Aug 2026 00:00:00 +0000

For several weeks, a strange thing was true of the Skywire network: a visor could be online continuously — process up, dmsg connected, reachable, everything green in its own logs — and the reward system would record its daily uptime at almost exactly 30%. Rewards require 75%. So a node that never went down earned nothing, and its owner had no way to see why. Roughly half the fleet was in this state.

Skywire Development Update — August 1, 2026

Sat, 01 Aug 2026 00:00:00 +0000

Today’s work sits mostly on the operator-facing surface: how a visor is tuned, how it’s controlled from the CLI, and how it self-describes. The routing examination continued paying out with a router change that races transport creation against routing over existing transports — so a warm peer connects in half a second instead of paying the full direct-dial latency first. The privacy and routing knobs that had been config-JSON-only got proper autoconfig/config gen flags and a tuning guide, a local privilege-escalation vector in RPC-initiated dmsgpty exec was gated behind opt-in, and cli visor app grew into the app-control superset that proxy and vpn can later alias. A stray Mixed-Content bug in the browser’s mesh navigation was also fixed.

Skywire Development Update — July 31, 2026

Fri, 31 Jul 2026 00:00:00 +0000

A dense fifteen-PR day across four fronts. The skychat group feature — a long-standing community contribution — landed with its admission control, encryption hardening, and the last open “ask again” item finished. The dual-surface divergence campaign reached its conclusion: skychat, the logs content, and the logs window all now render from one implementation on every surface, with the wasm desktop’s WinBox windows hosting the exact same Angular components the native node page uses. A performance push cut wasm-visor time-to-first-transport by more than half and killed the native visor’s five-minute autoconnect cold start. And the routing examination began yielding concrete controls — a per-type transport-creation policy, a shared cross-network fallback primitive, and a fix for a browser proxy that was dying on a two-route mux.

Skywire Development Update — July 30, 2026

Thu, 30 Jul 2026 00:00:00 +0000

The throughline today is the browser dmsg edge. A reachability campaign run down over the last stretch culminates in a fix to the deepest issue: a wss-only browser client was silently falling back to raw TCP it can’t dial, dead-ending connections that should have rendezvoused over WebSocket to the next server. That fix comes with a two-tier headless test harness so the browser edge — which the compile lane can’t cover — is finally regression-gated, plus an operator-run health probe that would have auto-caught the day’s real wss outage. The wallet also stopped shipping an 11MB copied tree and now serves straight from the vendored skycoin module, and the manager UI’s dependabot backlog was cleared in one batch. It was also the biggest Skycoin day in the window: all three Angular front-ends — the desktop wallet, skycoin-web, and the explorer — moved to Angular 22 and had strict TypeScript with strictTemplates turned on, new wallets began defaulting to bip44 (HD, multicoin), and a round of gnet and untrusted-input hardening landed underneath.

Skywire Development Update — July 29, 2026

Wed, 29 Jul 2026 00:00:00 +0000

Two threads today. The larger is a test-coverage pass over skychat that, by exercising the previously-untested code, turned up and fixed four latent bugs — including a data race in a shared CXO package and an empty-string public key that reached five endpoints as a real peer. The smaller thread is a run of wasm-hypervisor UI polish: the onboarding tour became non-blocking and told the real dmsg-carrier story, the wallet config overlay that had collapsed to an unusable strip was fixed, and the node info card now shows how a visor reached each dmsg server. Skycoin, meanwhile, spent the day on dependency maintenance ahead of the front-end toolchain work to come.

Skywire Development Update — July 28, 2026

Tue, 28 Jul 2026 00:00:00 +0000

The urgent item today is a reward regression the previous release introduced: after v1.3.89 restored the reward heartbeat, roughly half the fleet was recording only ~30% uptime while actually up — below the 75% reward threshold, so earning nothing. The fix runs the failure down to heartbeat under-delivery rather than any server-side scoring bug, and adds bounded backfill so flaky delivery no longer maps one-to-one to sparse uptime. Around it, the TinyGo wasm-visor got unwedged (a reflection panic that only fired inside the HV worker), the Bitcoin wallet’s electrum backend moved to where every other coin’s node lives, a flaky routing test got a real correctness fix behind it, and v1.3.91 was cut.

Skywire Development Update — July 27, 2026

Mon, 27 Jul 2026 00:00:00 +0000

The skychat convergence hit full stride today — eighteen PRs, most of them landing the payoff of yesterday’s seams. The centerpiece is a single shared DM controller that both the native app and the browser wasm visor now run on, deleting hundreds of lines of duplicated connection, read-loop, and send logic that had drifted between the two. With one core in place, the DM feature set that used to be implemented twice (or not at all on one surface) landed uniformly: delete-for-everyone, WhatsApp-style delivery ticks, and the quoted-reply UI reached both visors and both chat UIs at once. The day also brought a large browser-skychat feature merge, a config-regen fix that had been quietly making newly-shipped apps unreachable, and an RFC on serving SkyDEX as a plain website over dmsg.

Skywire Development Update — July 26, 2026

Sun, 26 Jul 2026 00:00:00 +0000

Today is the start of a multi-day skychat convergence push (tracked in #3596): the native app and the browser wasm visor have long carried two separate copies of the same chat machinery, and they’ve been drifting. The work begins at the two seams that let the rest converge — a wire format that carries quoted replies to the recipient rather than just the sender, and a history store that finally compiles under GOOS=js so the browser visor can adopt the same persistence the native app uses. Alongside the chat work, the TinyGo wasm-visor gained a runtime toolchain switch for A/B validation, and the packaging docs got a much-needed page on how installed nodes actually update themselves.

Skywire Development Update — July 25, 2026

Sat, 25 Jul 2026 00:00:00 +0000

A short day, spent making the browser hypervisor tell the truth. The AU miner owner reported that the wasm hypervisor’s node list looked broken next to the native one — managed visors showing Total: 0 transports, a single flat list where the native HV renders per-hypervisor clusters, and the whole thing flickering as visors blinked offline and back. All three are the same underlying gap: the wasm HV was rendering from partial mirror data over a marginal dmsg link. Today’s work closes those, then rebuilds the served blob so the fixes actually reach the PWA, and the network visualizer gets a small cosmetic win.

Skywire Development Update — July 24, 2026

Fri, 24 Jul 2026 00:00:00 +0000

Today’s work is a rescue. For days the fleet’s reward uptime had silently collapsed — hundreds of visors that were plainly online were recording almost no uptime and earning nothing for it — and the outage stayed invisible because every layer that could have shouted about it was logging at Debug or discarding the error entirely. The investigation ran the failure down to two independent causes, both fixed: the reward-critical TPD heartbeat had been quietly disabled when the standalone uptime tracker was decommissioned, and the visors that were heartbeating were losing an httpauth nonce race that 401’d most of their requests. Around those two fixes sits a ring of hardening — the residual TPD memory leaks closed, latent unbounded-timeout and unbounded-map bugs guarded, and the silent-failure logging that hid all of it turned up to Warn. The bottom line for operators: current-fleet visors must update to v1.3.89 to earn rewards correctly — the heartbeat fix is visor-side, and the release raises the auto-incrementing version floor. Also today, the .dmsg/.skynet LAN gateway got a config-safe path so one board can serve a whole home-router LAN. On the Skycoin side, the day was dependency housekeeping — the open Dependabot PRs batched into one branch.

Skywire Development Update — July 23, 2026

Thu, 23 Jul 2026 00:00:00 +0000

Two threads today, both about stripping dependencies out from under a running system. The VPN router’s control plane started moving off shell-outs to ip and iptables and onto native Go — netlink and nftables spoken directly to the kernel — which is the first real step toward shipping Skywire as a dependency-free gokrazy appliance that carries no iproute2 or userland at all. Separately, the long-running TPD reward outage got its first concrete fix: the CXO aggregator that receives every visor’s Roots was never pruning the superseded ones, and on the production TPD host that was leaking toward OOM at roughly a gigabyte a day.

Skywire Development Update — July 22, 2026

Wed, 22 Jul 2026 00:00:00 +0000

Today Skywire cut v1.3.88, and the release’s headline is the VPN router: over the last stretch it graduated from an on-the-bench prototype into a fully configurable, documented feature that any supported board can run. The bigger leap that rode in with it is the mesh gateway — a LAN device behind the router can now reach a .dmsg or .skynet service by name, with no per-device setup and no SOCKS proxy, because the router resolves the name to a synthetic IP and transparently proxies the connection over the mesh. Underneath the features, a cluster of VPN reliability bugs got run down: a port collision that made vpn-server unstartable on every hypervisor-connected board, and two tunnel-exemption bugs that left the VPN silently dead on common transport types. The dmsg deployment also split two servers onto new hosts. (The VPN router gets its own dedicated feature article — this daily covers the day’s router PRs at a normal pace and points you there for the full story.)

The Skywire VPN Router

Wed, 22 Jul 2026 00:00:00 +0000

Running a VPN has always been a per-device chore. You install a client on the laptop, another on the phone, a third on the tablet, and you hope the smart TV and the game console — which won’t run a client at all — simply do without. Skywire’s vpn-client was no different: it protects the one machine it runs on, and nothing else on the network.

Today’s release, v1.3.88, changes the unit of protection from a device to a network. The new vpn-router app turns a spare Linux board — a skyminer, a Raspberry Pi, any SBC with two network interfaces — into a plug-in privacy router. Everything behind it, wired or wireless, gets an address by DHCP and has its traffic NAT’d into the Skywire mesh VPN, with no per-device configuration. The phone that joins its WiFi doesn’t know Skywire exists; it just has a different public IP.

Skywire Development Update — July 21, 2026

Tue, 21 Jul 2026 00:00:00 +0000

Two of today’s fixes were the kind that take a service down or make it lie. One was a nil-dereference in IsRoot() that, on the static musl release binary, crash-looped every skywire command from init() — and had already taken the main hypervisor offline behind a wall of 502s. The other was the reward JSON endpoints returning each visor’s raw bandwidth byte count where the SKY amount should have been, so the hypervisor UI showed a visor’s 13-SKY reward as over a million. Alongside those, the VPN-router app finally got a config surface so it can be enabled the normal way, a wasm deep-link overlay stopped spinning against a visor that was already connected, and a routine vendor bump picked up a secp256k1 allocation win. That win came from the skycoin monorepo, where the ECmult precomp tables moved onto the stack for ~41% fewer bytes per ECDH.

Skywire Development Update — July 20, 2026

Mon, 20 Jul 2026 00:00:00 +0000

Two threads ran through today. One was operational safety: updating a visor over its own dmsgpty had been quietly dangerous, because autoconfig ends by restarting the service — which kills the pty session and the in-flight update along with it — so a --no-restart flag now lets the restart happen out-of-band as the last step. The other was closing config gaps: a v1.3.85 regression had silently emptied every visor’s country code, the skycoin-web wallet gained a serve toggle and a full capability-gated custody model, and an audit of the skywire.conf template turned up eight documented-nowhere knobs plus a hypervisor address filed under the wrong heading. In the skycoin monorepo the wallet’s status bar learned the node’s chain identity and its node settings escaped the wizard guard, and the SkyDEX exchange engine moved in — domain logic in skycoin, skywire wrapping only the transport.

Skywire Development Update — July 19, 2026

Sun, 19 Jul 2026 00:00:00 +0000

Today’s work was all plumbing, down in the layer where dmsg carries HTTP and CXO fans roots out to subscribers. A production profile of dmsg-discovery told the story that started it: the service was sitting at ~84% CPU with garbage collection burning most of it, and nearly three-quarters of every allocation traced to noise handshakes — because the net/http-free HTTP client dialed a brand-new dmsg stream on every single call and told the server to close it. That got fixed. So did a stall on the CXO broadcast path where a well-meant optimization had quietly serialized every publisher behind one encode, a build-breaking piece of dead code that kept the darwin and windows CI jobs permanently red, and a flaky test that had been miscounting an async register. The skycoin monorepo spent the day in the same layer, cutting the memory a large transaction history costs — streaming the API response and paging the GUI view — plus a round of dependency maintenance.

Skywire Development Update — July 18, 2026

Sat, 18 Jul 2026 00:00:00 +0000

Yesterday’s multicoin rework made the embedded wallet route every coin’s requests through the visor — but only the browser-tab wasm visor had ever actually been driven in a browser, so the native hypervisor-served wallet had a latent gap that surfaced today: skycoin-web’s Angular HttpClient issues its requests over XMLHttpRequest, and the native shim only intercepted fetch. Fixing that unblocked the create-wallet selectors, which needed a matching skycoin-web change to fill in. The day closed with an efficiency fix in the transport-discovery CXO node, where broadcasting a large root to hundreds of subscribers was re-encoding it once per subscriber. The matching skycoin-web change — the one that fills those newly-reachable create-wallet selectors — landed in the skycoin monorepo the same day.

Skywire Development Update — July 17, 2026

Fri, 17 Jul 2026 00:00:00 +0000

A big day, in the way that days get big when a production fire and a milestone feature land in the same twenty-four hours. A dmsg dependency bump had quietly flipped a default that took the data plane down fleet-wide, and undoing that sat next to a public-visor init stall it had exposed — two fixes that had to ship together. Alongside the firefighting: the browser visor finally got a small body, compiled under TinyGo and shipped next to the standard-Go blob; a brand-new app turned a visor into a WiFi router that puts a whole LAN onto the mesh with no client software; a leaked-connection deadlock deep in the transport-discovery CXO node got traced and broken; and the default binary shed about 44 MB with no loss of function. A stack of wallet, diagnostic, and CI hygiene work rounds it out. In the skycoin monorepo, the wallet’s pre-unlock disclaimer got the honest rewrite that the visor’s onboarding tour then folded in.

Skywire Development Update — July 16, 2026

Thu, 16 Jul 2026 00:00:00 +0000

The discovery and transport-discovery hosts had been running hot — 124% CPU, load hovering around 7 — and the culprit turned out to be the fleet talking to itself too eagerly. A dmsg server re-registers its discovery entry every time a client session comes or goes, and under a busy server that innocent bookkeeping was amplifying into a handshake storm that thrashed the discovery’s garbage collector. Today’s work bounds the amplifier at both ends. In the skycoin monorepo, two follow-ons to yesterday’s TinyGo build shrank the binary to its intended size and greened the lint checks after the upstream merge.

Skywire Development Update — July 15, 2026

Wed, 15 Jul 2026 00:00:00 +0000

A quiet, sharp-edged day: a pair of concurrency races that had been hiding inside the skynet server and the cxo Filler got pulled out of a larger exchange-engine branch and fixed on their own, so the reliability work wouldn’t have to wait on the bigger review. Both bugs were the same shape — a goroutine registering work on a WaitGroup at the exact moment another goroutine was tearing the whole thing down — and both are the kind of race that stays invisible until a CI runner or a production visor happens to interleave the two just so. In the skycoin monorepo the day was all about making a TinyGo build of the node real and shippable — porting the web wallet off gin, embedding the wasm that matches the toolchain, colored help without text/template, and a release job that actually produces a TinyGo archive.

Skywire Development Update — July 14, 2026

Tue, 14 Jul 2026 00:00:00 +0000

Today began with an audit of the transport bandwidth pipeline and found the rolled-up totals inflating throughput by roughly two — every network and per-visor aggregate had been reading a legacy combined field that summed both edges of a transport, each of which independently reports the full throughput. Fixing that read-side math corrected the dashboards immediately. A second transport-discovery bug explained why a freshly-booted visor’s routes 404’d for the first half-minute: the shared route-finder index was only refreshed on a 30-second ticker, so a new visor’s feed simply wasn’t subscribed yet — now it subscribes the moment the connection lands. Alongside the correctness work, transports gained a direction — every transport was originated by one side, and that in-versus-out distinction now shows in both the CLI and the hypervisor node list — the BTC-over-mesh gateway got its final blockers cleared and a health surface, and the wasm-visor’s auto-update became reliable enough to actually move connected tabs onto new builds. In the skycoin monorepo the same day cleared two of the daemon’s last TinyGo blockers — the real HTTPS API and the explorer — and landed the electrum and wallet-health source changes behind the gateway’s new connection surface.

Skywire Development Update — July 13, 2026

Mon, 13 Jul 2026 00:00:00 +0000

Yesterday the skycoin wallet became a hypervisor feature; today it grew teeth. Bitcoin now works in the mesh-served wallet — the browser has always done its own BTC key derivation, transaction building and signing, so all it ever lacked was chain data, and a small gateway that translates the wallet’s BTC calls to an Electrum backend supplies exactly that, keys and signatures never leaving the tab. That gateway landed natively and then in the browser tab, dialing clearnet Electrum servers over the mesh through a skysocks exit so the wallet’s chain queries are IP-anonymous. Around it, the wallet’s backend configuration — which had been reimplemented three separate times — collapsed into one shared /wallet/config page that every surface embeds, complete with curated electrum-server dropdowns and skysocks-exit pickers. Skychat, meanwhile, shed its last loopback TCP port and became truly in-process, and a shared resolver bug that had quietly broken .dmsg:port addresses everywhere got fixed. In the skycoin monorepo, the source-side changes the gateway vendors landed too — an electrum client and backend that take an injectable dialer, more lenient JSON-RPC error parsing, and a skycoin-web wallet that keeps a no-password seed across a refresh and can encrypt it with a password at creation.

Skywire Development Update — July 12, 2026

Sun, 12 Jul 2026 00:00:00 +0000

The browser and the native visor kept converging on the hypervisor UI today. The skycoin wallet — which had been a browser-tab feature — became something the native visor serves too, at the same same-origin /wallet/ path, proxying the node API over dmsg on the server side exactly as the browser proxies it in-tab; so the wallet is now a hypervisor feature, available with no separate process and no port, on either kind of visor. The browser tab, in turn, gained the apps-management surface and an “about” entry it had been missing, and the whole wallet configuration story got a proper panel. Underneath the features, a real node-list hang got fixed, and two reference documents landed.

Skywire Development Update — July 11, 2026

Sat, 11 Jul 2026 00:00:00 +0000

Yesterday’s coin-node discovery had a destination in mind, and today it arrived: a skycoin wallet that runs inside a browser tab, with its keys and wallets held entirely client-side and its only network traffic — the node API — routed over the encrypted mesh. It’s a direct substitute for the discontinued skycoin mobile wallets, needing no local full node and no clearnet. The same day, skycoin-web was folded into the visor’s internal-app model so it launches the same way everywhere, setting up the convergence between the host-native and browser paths.

Skywire Development Update — July 10, 2026

Fri, 10 Jul 2026 00:00:00 +0000

The day laid the groundwork for a skycoin wallet that runs in a browser tab with no full node and no clearnet. The pieces are a discovery contract — a generic coin service type — plus the visor-side wiring that reverse-proxies a fibercoin node’s HTTP API over dmsg and advertises it only while it’s actually answering, and two follow-on fixes that came straight out of testing it live against a real node behind Caddy. Alongside the coin work, a large test-coverage pass closed the gaps an earlier audit had flagged across the WASM builds, the service APIs, and the hypervisor Web UI.

Skywire Development Update — July 9, 2026

Thu, 09 Jul 2026 00:00:00 +0000

A broad hardening day. The centerpiece was a subtle autoconnect bug that could silently stop a visor from ever building transports again — root-caused from a five-day-old goroutine dump on a live node. Around it, skychat’s federated groups grew the machinery to actually converge: a receive-side roster reconciler, a roster broadcast so late joiners catch up, and genuine sender-side unsend. A “message me” deep-link, a Windows-installer upgrade fix, and a couple of infrastructure moves rounded it out.

Skywire Development Update — July 8, 2026

Wed, 08 Jul 2026 00:00:00 +0000

Yesterday voice landed as a working signaling-and-media engine that auto-answered every call with silence — a deliberate placeholder while the real audio path and a consent flow were built. Today that placeholder came off: skychat voice became a call you can actually hear, with real microphone capture and playback, an Opus codec, an explicit-answer consent gate, and an in-call spectrogram that doubles as the terminal’s “see the audio” view — all still riding the encrypted skywire transport with no raw-internet ICE. Every new piece was built the same way the rest of skywire is: pure Go, no cgo, no system libraries to link, so the default build is untouched.

Skywire Development Update — July 7, 2026

Tue, 07 Jul 2026 00:00:00 +0000

A big day for skychat: the mesh messenger grew two features that make it a real communication tool rather than a text demo — file sharing and real-time voice — both built on the same principle that everything rides the encrypted skywire transport and nothing touches the clearnet. Underneath that, a memory leak that had been quietly bloating the transport-discovery server to 4 GB got root-caused and fixed, and the committed browser-visor blob finally got its bloated git history pruned. This post walks the arc: the leak, file sharing on native and in the browser tab, and the voice stack from RFC to a working call.

Skywire Development Update — July 6, 2026

Mon, 06 Jul 2026 00:00:00 +0000

A heavy day on the browser visor and the tooling around it. The wasm-visor stopped re-booting itself every time you opened a tab, learned to narrate its own connection process instead of flashing a scary error during the connection window, and — in its single-file form — was made to run straight from file:// again. The transport graph was wired to source its data over dmsg so the standalone tool works against the dmsg-only deployment, and its GPU view learned to group by country like the flat view. Underneath all of it, a connection leak that had grown the transport-discovery node’s heap to ~4GB was tracked down and fixed, and the hypervisor UI gained a group-chat interface.

Skywire Development Update — July 5, 2026

Sun, 05 Jul 2026 00:00:00 +0000

A day about spreading load fairly and seeing the network you actually have. The headline fix ends a load imbalance across the dmsg fleet that had been quietly making delegated services — including the reward system — intermittently unreachable, by matching each client to what a server can actually take. Alongside it, the transport-graph tooling caught up to the fleet’s newer transport types and gained a GPU-backed view that can finally draw the whole topology without freezing, and the in-tab browser learned to wait out a transient connection window instead of showing an error.

Skywire Development Update — July 4, 2026

Sat, 04 Jul 2026 00:00:00 +0000

A big day with a single unifying idea running under most of it: stop telling services what to do one imperative call at a time, and instead publish desired state and let them reconcile. The transport registry moves from HTTP register/delete calls — which spammed the discovery service with 429s under churn and shutdown — to a declarative model where a visor publishes its transport list over CXO and the transport-discovery reconciles against it. The standalone reward server gets the same treatment, reading CXO feeds instead of HTTP. On top of that: a clearnet-to-dmsg deep-link gateway, a much-improved visor switcher in the hypervisor UI, a guided tour, and a batch of packaging and tooling fixes.

Skywire Development Update — July 3, 2026

Fri, 03 Jul 2026 00:00:00 +0000

The browser wasm-visor had a structural flaw that no amount of UI polish could fix: it ran on the page’s main thread, so the moment it did anything slow — setting up a skysocks route, say — the whole tab froze. Event loop stalled, buttons dead, nothing repaints. Today moves the visor off the main thread entirely and into a dedicated Web Worker, which is the right fix but a disruptive one: WebRTC and IP self-reporting both break in a worker context and have to be re-plumbed. The other half of the day is a route-lifetime fix on the native side that keeps multihop routes from dying under a browser, and the v1.3.79 release.

Skywire Development Update — July 2, 2026

Thu, 02 Jul 2026 00:00:00 +0000

Skychat is the oldest app in the tree, and it shows: it grew ad-hoc over the years into several parallel implementations, more than one message model, two generations of group chat, and a handful of transports — each added when it was needed, none ever unified. Today opens the refactor that fixes that. It starts where a refactor should: a written RFC that names the problem, a first shared primitive extracted out of the duplication, and a concrete payoff — federated group chat running inside the browser wasm-visor, in a desktop-style chat window. This whole batch shipped together as 3362.

Skywire Development Update — July 1, 2026

Wed, 01 Jul 2026 00:00:00 +0000

Today pushed the WASM visor toward being a full-fledged hypervisor in its own right. It gained the network-visualizer, skysocks-lite controls, and skychat that the native UI has, and — underneath — CXO was made to build and run inside a browser tab so a WASM visor can report its own transport telemetry to the TPD. Getting CXO to compile under js/wasm meant splitting its on-disk storage behind a build tag.

Skywire Development Update — June 30, 2026

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

The theme today was cutting external dependencies out of the transport layer. dmsg gained the ability to serve secure WebSockets itself, obtaining its own certificate via Let’s Encrypt, so a dmsg server no longer needs a Caddy reverse proxy in front of it to reach browsers. WebTransport was folded onto the same unified transport port as the QUIC-based transport, and the hypervisor mini-desktop got a real window manager.

Skywire: Built-In Secure WebSockets

3356 feat(dmsg): optional built-in wss via Let’s Encrypt autocert (no Caddy required) lets a dmsg server terminate secure WebSockets on its own. Browsers on HTTPS pages can only open wss:// connections, and dmsg servers previously spoke plain WebSocket — so reaching them from a browser meant standing up Caddy (or another reverse proxy) in front of each server just to add TLS. This wires an autocert manager directly into the dmsg server: it obtains and renews a Let’s Encrypt certificate itself and serves wss:// natively, removing the reverse proxy from the deployment entirely.

Skywire Development Update — June 29, 2026

Mon, 29 Jun 2026 00:00:00 +0000

Packaging and configuration cleanup day. The Windows and Debian installers were fixed to run the right first-boot configuration step, the deployment config moved toward a single dmsg-only source of truth with the clearnet URLs stripped out, and the CLI stopped hardcoding clearnet help URLs in favor of ones sourced from the deployment. A raw-byte splice fix for the skynet web proxy and more mini-desktop UI work rounded it out.

Skywire: Installers Run the Right Autoconfig

3351 feat(win+autoconfig): Windows postinstall runs skywire autoconfig; autoconfig is PATH-independent fixes what a fresh Windows install does on first boot. The postinstall step now runs skywire autoconfig — the correct, complete configuration entry point — and autoconfig itself was made PATH-independent so it works regardless of where the installer placed the binary or whether the shell environment has been set up yet. 3349 fix(deb): postinstall runs skywire autoconfig, not skywire-cli visor gen-config applies the same correction to the Debian package, which had been calling the lower-level gen-config directly and missing the surrounding setup that autoconfig performs.

Skywire Development Update — June 28, 2026

Sun, 28 Jun 2026 00:00:00 +0000

A quieter day spent turning the hypervisor UI into an actual browser. The native and WASM hypervisors both grew a virtual browser for reaching skynet and clearnet sites through the visor, and the two front-ends were brought onto the same shared code so they stop diverging. Alongside that, a rewards accounting fix closed a bonus-splitting loophole, and a couple of small transport and skychat fixes landed.

Skywire: A Browser Inside the Hypervisor

3340 feat(visor): skynet/clearnet virtual browser in the native HV UI (shared browse.js) brings the browsing surface that already existed in the WASM hypervisor into the native hypervisor UI, and — importantly — does it by sharing a single browse.js between the two front-ends. Both hypervisors now drive the same fetch-and-render logic, so a fix or feature in one lands in the other for free instead of being re-implemented and drifting apart.

Skywire Development Update — June 27, 2026

Sat, 27 Jun 2026 00:00:00 +0000

Yesterday gave the browser visor plain-WebSocket reachability; today’s problem is that a browser visor served over HTTPS can’t open a ws:// connection — the browser blocks the mixed-content downgrade, and public dmsg servers only speak plain WebSocket. The fix is a two-stage bootstrap: connect over wss:// just long enough to get onto the network, then hand off to WebTransport for the real session. That handoff drove a cleanup of the whole transport-type taxonomy, and around it the wasm visor kept filling in native parity — an in-process skychat, served peer interfaces, its own routing tab — while the hypervisor UI learned to tell a browser visor apart from a native one at a glance.

Skywire Development Update — June 26, 2026

Fri, 26 Jun 2026 00:00:00 +0000

A dense day of transport-layer work, all pointed at one goal: letting a visor that runs entirely inside a browser tab reach the rest of the network — and letting the rest of the network reach it back. Browsers can’t open raw sockets, so a wasm visor is confined to the transports the browser exposes: WebSocket and WebTransport. Today’s changes teach the address-resolver to advertise those endpoints, teach native visors to dial them, fold a WebSocket listener onto the existing stcpr port so every visor is reachable by a browser without opening a new port, and then wire the wasm visor to autoconnect over both. The result is a browser tab that discovers public visors and dials them the same way a native visor does.

Skywire Development Update — June 25, 2026

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

Where the previous day proved a browser tab could act as a visor, this one made the native and in-tab visors share the code that makes them work — so they stop drifting apart. The centerpiece is visorcore: a set of refactors that pull service resolution, the register-before-serve dmsg invariant, and router construction into one shared assembly used by both backends. Around it, the dmsg client learned to register seeded edge clients correctly so a browser visor actually appears in discovery, a WebSocket transport was unified onto the dmsg-server’s main port, and hv serve grew the ability to serve the wasm-visor with the browse/host overlay. This post traces the convergence, the discovery fixes it depended on, the WebSocket unification, and the serving path.

Skywire Development Update — June 24, 2026

Wed, 24 Jun 2026 00:00:00 +0000

A day spent turning the browser tab into a full participant in the network. The wasm-visor gained a standard-Go js/wasm build that unlocks the real crypto/tls and net/http stacks inside the tab, a yamux RPC bridge so skywire cli can drive that tab exactly as it drives a native visor, the route-origination machinery a visor needs to actually reach the mesh, and a shared browse/host engine for loading dmsg-hosted sites in-page. The blob that carries all of this now ships embedded in the binary by default. This post follows the arc from build toolchain, to control plane, to browsing, to distribution.

Skywire Development Update — June 23, 2026

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

Yesterday the visor learned to run in a browser tab; today it learned to talk to peers the way a browser can and to serve the dmsg web from inside the tab. Three threads ran in parallel. The first is WebRTC as a genuine Skywire transport — added natively with pion, given a browser carrier that can both dial and accept, and turned on by default so any visor accepts every transport type it’s capable of. The second is the unified transport port: a reworking of how a visor binds its listeners so that multiple transport types can share a single TCP or UDP socket, shrinking the visor’s port footprint. The third closes the wasm-visor story from the day before — a browser tab can now fetch content over dmsg, render a dmsg site in a sandboxed iframe, and even self-host content that other nodes fetch back.

Skywire Development Update — June 22, 2026

Mon, 22 Jun 2026 00:00:00 +0000

Today the visor learned to compile under TinyGo, and then to assemble itself inside a browser tab. This is the build-out of the wasm-visor: a real Skywire visor — router, transport manager, app server, and a hypervisor UI — running entirely in-browser as WebAssembly, reachable and routable over the same network as a native node. Getting there meant porting one subsystem at a time to a toolchain that has no net/http, no net/rpc, and no TCP ingress, then bolting the ported pieces together into a working “edge” visor and giving it browser-native ways to dial its peers. The day’s PRs read like a checklist of that ascent: package-by-package TinyGo compilation, a reflection-free gob RPC shim to replace net/rpc, the edge assembly itself, and the first two visor-to-visor transports a browser can actually open — direct WebSocket and direct WebTransport.

Skywire Development Update — June 21, 2026

Sun, 21 Jun 2026 00:00:00 +0000

Two threads from the week converge into shippable artifacts today. The browser-hypervisor work reaches its natural endpoint: a single self-contained hypervisor.html file, assembled by a generator, that inlines everything it needs to run a serverless visor UI from one artifact. And the embedded push clears a real milestone — the dmsg client now compiles under TinyGo for wasip1 and IoT targets, which meant extracting QUIC behind an interface and, along the way, catching two latent QUIC stream bugs. A wallet-like key ring for deterministic derived keys and a Windows test flake fix round out the day.

Skywire Development Update — June 20, 2026

Sat, 20 Jun 2026 00:00:00 +0000

With WebSocket and QUIC carriers landed the day before, today the browser finally becomes a first-class citizen of the mesh. A WASM dmsg client compiles and runs in a browser tab, and a serverless hypervisor UI runs entirely over dmsg — no clearnet, no hosting a control surface on a domain. A fourth dmsg carrier, WebTransport, lands alongside it for CA-free browser reach. Underneath, the discovery layer sheds the last of its plain-HTTP fallbacks so that discovery is now strictly dmsg, and the TinyGo logging groundwork is generalized in preparation for an embedded dmsg port.

Skywire Development Update — June 19, 2026

Fri, 19 Jun 2026 00:00:00 +0000

The day the transport layer grew two new legs and finished a long-running one. Two efforts landed side by side: a fresh push to give dmsg more ways onto the wire — carrying dmsg sessions over both WebSocket and QUIC — and the final assembly of the multi-year “faithful UDP” work (issue #2607), where UDP semantics are preserved end to end instead of being papered over by a reliable stream. QUIC ties the two together: it brings native datagrams that faithful UDP can ride on directly, and it becomes a first-class skynet transport in its own right. A slimmer end-to-end test harness and a cleaner split between the hypervisor’s web UI and its RPC round out the day.

Skywire Development Update — June 18, 2026

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

The most important day in a while, and it started with the network down. The dmsg-only convergence work of the prior days, combined with a fleet-wide redeploy, walked straight into a cold-start bootstrap trap: every dmsg-server was waiting on a registration that could only succeed once another server was already accepting — a circular dependency where nobody could be first, so the whole fleet stayed down even though every binary was healthy. Untangling it took a chain of fixes that each peeled back one layer of the trap, and once the network was back up, a multi-agent code audit of the v1.3.72–76 dmsg changes turned up a long tail of leaks, races, and “looks-healthy-but-can’t-relay” failure modes — all fixed the same day, culminating in the v1.3.76 release. This post traces the arc: the outage, the root cause, the audit, and a hard-fail defense against silent post-quantum downgrades.

Skywire Development Update — June 17, 2026

Wed, 17 Jun 2026 00:00:00 +0000

The big structural change of the day was collapsing the visor’s two same-key dmsg clients into one — and the bumpy path it took to land. The visor had been running a discovery client and a direct client under the same public key, and because dmsg servers evict by newest-session-wins, the two were quietly evicting each other on every shared server: a continuous self-eviction storm measured at tens of session-deaths per minute per server. The fix went in, got reverted when it surfaced a fatal re-entrant deadlock, and was re-applied with the deadlock fixed. Around that headline: a clutch of resolving-proxy alias features (including a clickable home.dmsg directory page), a redis-starvation fix in service discovery, a dmsg-server config simplification, and the noise-fork PQ design doc catching up to the code.

Skywire Development Update — June 16, 2026

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

The headline is post-quantum cryptography landing in the Noise handshake. Over three pull requests — a design sketch, a self-contained crypto layer, and the live wiring — skywire’s encrypted transports gained a hybrid X25519 + ML-KEM-768 key agreement, with no new round trips, no flag to flip, and full backward compatibility with peers that haven’t updated. Around it: an end-of-month docs refresh of the reward rules to match the current dmsg-only deployment, two transport-reliability changes aimed at dead-edge detection (OS-level keepalive and a local-route-calc preference for disjoint mux legs), and the migration off the frozen noise fork that made the PQ work possible in the first place.

Skywire Development Update — June 15, 2026

Mon, 15 Jun 2026 00:00:00 +0000

A short but consequential day, with two changes that each close a gap the old code couldn’t see. The router gains a per-leg end-to-end liveness probe, so a multiplexed route whose path dies beyond the first hop is detected and dropped instead of silently black-holing traffic. And the rewards regional-saturation formula is reworked so that running more visors at a country’s IP grows the country’s pot proportionally rather than freezing it at the single-visor amount — fixing a case where adding visors actively diluted everyone’s reward.

Skywire Development Update — June 14, 2026

Sun, 14 Jun 2026 00:00:00 +0000

A day of grounding the dmsg-only default in reality: as the network leans harder on the overlay, the failure modes that used to be masked by a plain-HTTP fallback now have to be fixed properly. Two of them were boot-and-reconnect wedges — a dmsg-only visor that spun forever trying to reach the transport-discovery, and a SUDPH client that retried a closed socket until it gave up. Alongside those, a new inject_pk mode makes forwarded websites HTTP-aware (the backend finally learns who is connecting), the router’s setup-failure diagnostics are made panic-safe and then richer, and a couple of CLI/UI papercuts get smoothed.

Skywire Development Update — June 13, 2026

Sat, 13 Jun 2026 00:00:00 +0000

A day that follows the plain-HTTP retirement to its logical conclusion: if deployment services live on the overlay, you need a clean way to see them from a browser without a clearnet hop — and that way is the resolving SOCKS5 proxy. The headline work makes those .dmsg / .skynet proxies smarter: a visor asked for its own key now short-circuits in-process instead of dialing a wasteful round-trip back to itself, and a configurable alias lets skywire.dmsg mean “the local visor’s landing page.” Around it: the CLI finally drops its dead plain-HTTP fallback (the resolver is the supported replacement), a discovery-side timeout-and-hang fix on /uptimes?v=v3, a self-healing --direct route for control-plane forwards, and the real fix for a dmsg-discovery CPU storm that had been pinning the service for hours.

Skywire Development Update — June 12, 2026

Fri, 12 Jun 2026 00:00:00 +0000

The headline is persistent pty sessions: the hypervisor web terminal can now drop, reconnect, and rebind to the same shell with its missed output replayed — built up across four self-contained phases so the concurrency-critical core was validated before anything touched the host’s hot path. Around it, a receive-side route-setup race gets fixed by parking frames instead of dropping them; the CLI stops silently serving stale cache data when you asked for fresh; minimal visor configs finally seed the direct-service entries they need to reach TPD over dmsg; the web terminal works for sub-hypervisor visors; and reward lookup and hv ls --load give operators two new windows over dmsg.

Skywire Development Update — June 11, 2026

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

A day spent making things recover from failure instead of silently wedging on it. skysocks-client’s reconnect loop finally fires on the failure that matters most — a route group torn down router-side without an EOF — and interactive pty terminals stop dying every two minutes of idle. Underneath, a sustained adversarial audit during a live deploy-churn window turned up a string of churn-exposed leaks, races, a crash, and a transport-eviction bug that was breaking routes for minutes at a time. Plus a --cascade config flag so operators can opt into the source-driven route setup, and a documented hook for restarting out-of-tree services after an auto-update.

Skywire Development Update — June 10, 2026

Wed, 10 Jun 2026 00:00:00 +0000

A heavy day on two fronts. The first is the dmsg server: it stops booting on plain HTTP entirely — building its transit client before the server, registering and resolving strictly over dmsg, falling back to the embedded deployment config when no block is set, and self-updating its embedded server list over dmsg — and it gains a way for a non-public server to be reachable inbound via signed peer announcements. The second is the adaptive routing arc for multiplexed proxies, which lands its full observable → manual → adaptive control loop: mux-set to reconcile a leg-set, mux-auto to prune toward a latency preset, and the GROW direction so a session re-grows lost redundancy. Around those, a long run of lifecycle-audit fixes hardened the router, transport, dmsg session, and CXO layers against leaks and races found during live deploy-churn.

Skywire Development Update — June 9, 2026

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

A day of sharpening the tools you measure and operate the network with. The route-finder learns to hand back per-hop latency so a client can rank routes without re-probing them; the proxy mux-info view gains a live throughput-and-share readout so you can see what a multiplexed session is actually delivering right now; and the CLI takes another step off the plain-HTTP edge of the deployment services. Underneath that, two leaks and a race get root-caused — a CXO publisher heap leak that was OOM-looping the transport-discovery in hours, and a router data race that turned out to be the real cause of the linux CI failures.

Skywire Development Update — June 8, 2026

Mon, 08 Jun 2026 00:00:00 +0000

A day with two threads running in parallel: making multihop route setup tolerate the network’s churn instead of failing on it, and giving the resolving proxy real source-routing power. The route-setup work adds a per-hop id-reservation retry on transient dmsg-202 and replaces dmsgweb’s reconnect storm with a single client. The resolver work lets you name a dmsg rendezvous server or an exact transport path right in the hostname — pinning how a .dmsg or .skynet address is reached. Around them: latency-weighted route selection becomes the finder’s default, debug logs and pprof get consolidated onto one dmsg port, and a third CXO goroutine leak is closed.

Skywire Development Update — June 7, 2026

Sun, 07 Jun 2026 00:00:00 +0000

The day the dmsg session lifecycle finally got fixed — the change that was the real root cause behind “dmsg error 202” and the per-hop coin flip that made multihop route setup unreliable for months. Newest-session-wins replaces a lifecycle that rejected healthy reconnects and clung to half-dead corpses. Alongside it: bounding the mux-bandwidth RTT probe so it can’t hang the run, and a hypervisor UI pass that adds a DMSG-server IP column, fixes text contrast, and declutters the skynet forms.

Skywire Development Update — June 6, 2026

Sat, 06 Jun 2026 00:00:00 +0000

A day spent unsticking the things that quietly leak, wedge, or fall back to plain HTTP. The headline is a dmsg-only fix for the blank hypervisor network tab — a casualty of the new default config — alongside a setup-node connection pool that stopped handing out dead connections and a CXO goroutine leak that was dragging whole hosts down. Around them: the rewards calc sourcing uptime from the transport-gated tracker, and the got CLI learning to actually use its SOCKS5 proxy.

Skywire Development Update — June 5, 2026

Fri, 05 Jun 2026 00:00:00 +0000

A big day the day after a release, and the dominant thread is multihop route setup again — but this time with a hard, pragmatic pivot. Live A/B testing showed the new source-driven cascade installs routes whose control plane succeeds on every hop yet whose data plane doesn’t carry traffic, so the default flips back to legacy direct-dial route setup while the cascade’s data-plane bug is chased down, with the dial loop hardened to walk more candidate intermediates and a mux that now self-heals its degree in the background. Around it: a benevolent bandwidth-spreading routing-policy preset, a TPD fix that keeps both edges of an expired transport (worth ~half the network’s bandwidth rewards), a launcher fix that had the skysocks- and vpn-clients dead on arrival, a synchronous bbolt integrity walk that stops ARM boards crash-looping, the ssh/sshd/sshfs commands unified under cli pty, and a clutch of CXO, skychat, and logserver ergonomics.

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.

Skychat: Group Messaging on a Peer-to-Peer Mesh

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

Skychat is the chat application that ships with skywire — direct messages and group conversations between visors. It is also, quietly, one of the best stress tests the project has. A group chat exercises almost everything underneath it at once: the encrypted transport mesh, the CXO data layer that synchronizes shared state, presence and reconnection, and the unforgiving question every messaging system eventually faces — when you send a message, does it actually arrive?

Skywire Development Update — June 4, 2026

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

A big day, the day after a release. v1.3.64 shipped, and then the work turned to the thing that had been making multihop routes unreliable for months: route setup. The headline is a redesign of how routing rules get installed — the route-setup node stops dialing every hop over dmsg and becomes a pure signing oracle, with the source injecting the signed rules down the route’s own transports. That gets its own article; it took five pull requests and a lot of live debugging to land working end-to-end. Around it: a sudph reliability fix so visors recover after an address-resolver restart, a route-finding correctness fix, two new standalone diagnostic tools (a dmsg probe and a skywire-native sshfs), the cli version command, and a handful of post-release cleanups.

Skywire Development Update — June 3, 2026

Wed, 03 Jun 2026 00:00:00 +0000

A day about taking plain HTTP off the critical path. With the overlay’s reliability and egress now in good shape, the default generated config drops the plain-HTTP service-discovery fallback — services are reached over the peer-to-peer overlay (dmsg today, skynet transports by design). Plain HTTP now survives only as a compatibility shim for custom deployments; on the public network it’s headed for the door entirely. Getting there safely meant draining “ghost” transports at the source, cutting the transport-discovery’s egress with gzip + caching, and bounding a runaway CXO goroutine spawn. Plus the Windows installer is fixed and v1.3.64 is prepared.

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 — June 1, 2026

Mon, 01 Jun 2026 00:00:00 +0000

The standalone chat path reaches its purest form: CXO-backed group messaging over native TCP, peer-to-peer, with no dmsg involved at all — just two public keys and an encrypted transport between them. Plus transitive hypervisor trust, a per-server service health check, and a cluster of router and CXO fixes (one of which we’ll revisit later in the month).

Skywire: Standalone Skychat — CXO Over Native TCP, No DMSG

2950 feat(skychat): CXO-backed messaging over native TCP in standalone (P2P, no dmsg) — the standalone chat app can now run its CXO-backed group messaging directly over a noise-encrypted native-TCP connection between peers, with no dmsg layer at all. Each instance is identified by its public key; the noise handshake encrypts the link; CXO feeds carry the messages. Two (or more) peers point at each other’s pk@host:port and have a working, encrypted, public-key-authenticated group — no visor, no router, no dmsg server, no discovery service.

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 30, 2026

Sat, 30 May 2026 00:00:00 +0000

A light day. The node survey learns to report CPU details on the hardware skywire actually runs on — ARM single-board computers and Windows — and the hv ls listing gains multi-section output with aligned columns.

Skywire: Survey — CPU Info on the Real Hardware

2934 feat(survey): internalize zcalusic/sysinfo + populate CPU on ARM SBCs and Windows — the node survey (the hardware/OS inventory a visor reports) internalizes the zcalusic/sysinfo library and fills in CPU details on the platforms where it was previously blank: ARM single-board computers (the Raspberry-Pi-class hardware much of the network runs on) and Windows. Internalizing the dependency also means the survey isn’t at the mercy of an external library’s platform gaps — the code that needs fixing is in-tree.

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.

Skywire Development Update — May 27, 2026

Wed, 27 May 2026 00:00:00 +0000

A big structural day. Two long-running refactors converge: the unified app framework (#2775) names the implicit contract every skywire app has been following and starts folding the built-in services into it, and the pty rename finishes de-coupling the pty subsystem from dmsg — pkg/dmsg/dmsgpty becomes pkg/pty, because the pty runs over dmsg, skynet, tcp, or http, and the name should say so. Plus the pair-binary collapse and a round of hypervisor-cache tuning that produces two patch releases.

Skywire Development Update — May 26, 2026

Tue, 26 May 2026 00:00:00 +0000

A refactoring-heavy day with one clear goal: make the visor config generator compile to WASM under TinyGo, so the install-command generator page can build a real config in the browser from the live flag set. That meant surgically removing net/http and encoding/json from the config-gen build graph and hand-rolling a streaming JSON serializer. Alongside, the skypty-over-skynet listener gets the fixes that make it actually start and accept connections.

Skywire: A WASM-Clean Config Generator

The install-command generator lifts skywire’s own autoconfig flag set into a browser form via a TinyGo-compiled WASM blob — so the flags shown always match the binary. To generate a config in the browser (not just assemble a command line), the config generator itself has to compile under TinyGo, which is strict about what packages it accepts. Today does that surgery.

Skywire Development Update — May 25, 2026

Mon, 25 May 2026 00:00:00 +0000

The CLI’s connection to a visor gets unified around one idea: address a visor by its public key and reach it over whichever transport works. --rpc and --via now accept both dmsg://<pk> and skynet://<pk>, the dmsg and skynet bridges fold into a single RPC surface, and --via skynet:// works end to end. The control plane gets the same both-transports-are-first-class treatment the data plane already had — plus self-healing for degraded dmsg.

Skywire Development Update — May 24, 2026

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

The management plane starts moving onto the overlay. Visor↔hypervisor RPC and the pty session can now auto-upgrade to skynet — carrying control traffic over skywire’s own routed transports rather than only over dmsg. The pty UI gets a skypty-ui rebrand, the installers get a round of fixes (and the groundwork for generating the config at install time), and two patch releases go out.

Skywire: Management Over Skynet

Control traffic — the RPC a hypervisor uses to drive a visor, and the pty session an operator opens into it — has historically ridden dmsg. Today it learns to ride the routed overlay too.

Skywire Development Update — May 23, 2026

Sat, 23 May 2026 00:00:00 +0000

A heavy day, and a release. The routing layer learns asymmetric, latency-ranked path selection — forward and reverse legs can carry different route counts and minimum hops, and candidates are ranked by measured per-hop latency rather than picked arbitrarily. Transport discovery becomes CXO-aware: local route calculation reads the transport graph from the CXO feed before reaching for HTTP. The hypervisor gains real drill-down — proxying RPC through a sub-hypervisor to manage visors nested behind it — plus runtime management commands. And it all ships as v1.3.54.

Skywire Development Update — May 22, 2026

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

A small, consolidating day. The --min-hops constraint finishes its journey through the app dial chain, ping gets a hard timeout, and a subtle CXO prefix-matching bug gets fixed.

Skywire: Min-Hops Through the App Dial Chain

The minimum-hop-count constraint — force a dial onto the overlay rather than letting it take a direct shortcut — needs to be honored all the way from the app down to the router. Today closes the last gaps.

Skywire Development Update — May 21, 2026

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

A routing-correctness day. The local-route calculator gets a proper N-hop BFS so multi-hop local routes are found deterministically and honor a minimum hop count, and the mux-bandwidth and ping paths get a round of race fixes and failure-surfacing so the measurements are trustworthy.

Skywire: Local Routing — Deterministic N-Hop BFS

When a route can be assembled from transports the visor already knows about (without consulting the route-finder service), it does so locally. That local calculation needed to be both correct and deterministic.

Skywire Development Update — May 20, 2026

Wed, 20 May 2026 00:00:00 +0000

The multiplexed-routing work gets serious about measurement. A new StreamMuxBandwidth RPC and a cli mux-bw command — with a live TUI dashboard — turn “route a flow over N disjoint paths” into measured throughput, queueing delay, and an idle baseline. The DialOptions grow disjoint-mux and intermediate-exclusion controls so the paths can be forced apart. Alongside, a round of hypervisor-UI fixes and a couple of router correctness fixes.

Skywire: Multiplexed Bandwidth — Measure the Disjoint Paths

If multiplexed routing is the headline capability, it needs to be measurable. Today builds the instrument.

Skywire Development Update — May 19, 2026

Tue, 19 May 2026 00:00:00 +0000

A shorter day, with three through-lines: the ping tree diagnostic moves to a server-side gRPC stream, parallel multiplexed-route dialing gets a --routes knob (and a CI harness to assert on it), and the storage layer learns to auto-recover from bbolt corruption instead of crash-looping on it.

Skywire: Ping-Tree — Server-Side Streaming

The ping tree view — which walks the route tree to a destination and times each hop — moves its heavy lifting server-side.

Skywire Development Update — May 18, 2026

Mon, 18 May 2026 00:00:00 +0000

Two foundational threads today. The big one is IPv6 dual-stack — issue #1525 lands across the schema, the address resolver, the dmsg-server advertisement, and a Happy-Eyeballs dialer, in a tidy phased rollout. The other is the standalone skychat path: a noise-TCP direct connection (encrypted, public-key-addressed) plus a --standalone mode that runs the chat app with no visor process behind it — just the encrypted connection and a pubkey identity. Plus the usual CXO/pairing reconnect hardening and the start of a CI mux-route probe.

Skywire Development Update — May 17, 2026

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

Two threads dominate today. First, skychat’s pairing path — direct, one-to-one CXO-backed messaging — gets its own baseline tests and CLI surface, sitting alongside the group path. Second, the skychat-group gossip model shifts to an admin-aggregator, full-mesh topology with signed mutations and signed leaf messages, dropping the older admin-mirror feed scheme. Underneath, a cluster of CXO node/skyobject/cxds fixes, and dmsgpty’s MultiDialer grows a skynet listener and dialer — pty reaching a peer over skywire’s own p2p transports, not only dmsg.

Skywire Development Update — May 16, 2026

Sat, 16 May 2026 00:00:00 +0000

A heavy reliability day. The skychat-group work keeps closing the gap between “a message was sent” and “a message was delivered” — a fresh wave of per-layer drop counters and per-peer last-inbound surfaces make the receive path observable, while signed roster/admin gossip and history-replay-beyond-the-ring harden it. Underneath, the CXO node and treestore get a cluster of restart- and rejoin-robustness fixes, the hypervisor gains a nested-visor tree view (backend + UI), and dmsgpty starts a two-phase dialer refactor.

Faithful UDP-Over-Skynet

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

Skywire has always carried TCP traffic well. Route groups are reliable, ordered, head-of-line-blocked on packet loss — exactly the contract net.Conn callers expect. That’s the right shape for HTTP, SSH, raw TCP forwarding, and almost everything else apps reach for by default.

But real-world UDP applications — DNS, NTP, VoIP, gaming, QUIC, anything that has its own loss-tolerance built in — treat late packets as worse than lost packets. A DNS resolver that retries after 100ms doesn’t want the original response to arrive 5 seconds later through a TCP-shaped tunnel. A VoIP codec that masks 20ms of lost audio doesn’t want all subsequent audio to wait while the lost packet retransmits. A gaming engine doesn’t want the world-state update from a frame ago — it wants the current update or nothing.

Skywire Development Update — May 15, 2026

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

The faithful-UDP arc lands. Five stacked PRs add UDP-over-skynet end to end: wire type, route group, per-datagram AEAD, the visor-side bridge for forwarded ports, and the app-API surface for DialPacket. Plus a standalone skyudp-bridge (sibling to skymail-bridge) and the next round of skychat-group reliability fixes — the cascade that produces the subscriber_alive auto-recovery story.

Skywire: Faithful UDP-Over-Skynet (Stages 1–5)

The architectural problem: skywire’s route groups have always been TCP-shaped — ordered, reliable, head-of-line-blocked on packet loss. Most real-world UDP traffic (DNS, NTP, VoIP, gaming, QUIC) treats late packets as worse than lost packets. Tunneling UDP through a TCP-shaped stream defeats the point.

Skymail-Bridge: Email Over Skywire

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

Email is the oldest addressable identity on the internet, and it’s been outside Skywire’s reach since the project began. Today’s PR #2598 closes that gap: skymail-bridge — a sender-side SMTP bridge that lets an operator send email to and receive email from a Skywire identity, using the same Postfix machinery they already run.

The address shape

A Skywire identity is a 33-byte compressed secp256k1 public key. Base32-encoded (RFC 4648), that’s 52 characters — small enough to fit inside RFC 1035’s 63-octet DNS label limit, which is the hard constraint email addresses have to live within. Hex would be 66 characters and break.

Skywire Development Update — May 14, 2026

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

Largest day on develop in recent memory. Three big arcs land: federated send for group chat (members publish to their own feeds instead of relaying through the owner), the admin-role + admin-mirror cascade, and the skymail-bridge for email-over-skywire. Plus a sweep of fixes to the per-peerSub liveness model from yesterday, the dmsgpty-via-visor-RPC routing, and specs cleanup.

Skywire: Skychat/Group — Federated Send

PR #2580 inverts the v1 model. Pre-fix: only the owner published; members had to route through the owner’s relay listener (PR #2506). Post-fix: every member publishes to their own per-PK feed; other members subscribe to every other member’s feed.

Skywire Development Update — May 13, 2026

Wed, 13 May 2026 00:00:00 +0000

The day after the v1.3.53 ship: most of the work is on the chat-app’s subscriber-liveness model. Four flags collapse into one, and a watchdog plus a fan-out fix shake out the remaining false negatives on subscriber_alive.

Skywire: Skychat/Group — Unified Liveness Signal

PR #2537 is the cleanup: four separate liveness fields collapse into a single lastInboundNs (atomic int64, set on every observable inbound event). The old fields were:

Session.subAlive bool — toggled on Connect / Close
Session.lastHeartbeatNs — heartbeat-only signal
Record.LastMessageAt — chat-only, persisted
Record.Status — configuration state pulling double duty as health

They kept disagreeing. Each pair-wise disagreement got its own fix (PRs #2530–#2534 in this same arc) and the holistic answer was a single timestamp that’s computed from events instead of stored in multiple places.

Skychat D1: Group Chat Over CXO

Tue, 12 May 2026 00:00:00 +0000

Skychat got DM-shaped messaging years ago. Group chat is a different shape — multi-party, lossy-tolerant, with members joining and leaving — and it’s been an open feature gap. Today’s PR stack ships D1 group chat: the first design iteration, owner-centric, riding on CXO feeds, with end-to-end encryption optional via per-group AES keys.

The D1 model

D1 picks the smallest viable shape that lets a group of people exchange messages reliably:

Skywire Development Update — May 12, 2026

Tue, 12 May 2026 00:00:00 +0000

A massive day for skychat. The chat-app gets group chat, encrypted DM, per-PK aliases, history replay, peer-receipt acks, a unified CLI TUI, and the dmsgscp utility — all merged today. v1.3.53 ships at the end.

Skywire: Skychat D1 — Group Chat over CXO

PR #2505 introduces D1 group chat. The model: one member owns the group’s CXO feed and publishes messages; other members subscribe (read-only in v1; PR #2506 adds member-side relay).

Skywire Development Update — May 11, 2026

Mon, 11 May 2026 00:00:00 +0000

Skywire: v1.3.52 — Network-State + Observability Release

PR #80c2fd2c1 cuts release v1.3.52, capping the network-state arc that ran from late April through last week. Headline items in the release:

DHT removal in favor of CXO + HTTP discovery (#2459)
pkg/services framework with single-process multi-service supervisor (#2464–#2472)
Single-container CI e2e (#2471)
CXO publishers on every authoritative source; CXO subscribers replacing HTTP polls across the visor and tpviz (#2456–#2463)
dmsgfirst APIClient with HTTP fallback (#2433, #2441)
Per-transport latency end-to-end (#2401)
Transport uptime via CXO-driven heartbeats with minute granularity (#2426)
Stats / serviceuptime / version provenance in local bbolt (#2428)
WAN-reachable hypervisor-embedded dmsg + discovery proxy + terminal persistence (#2450)

The release lines up the network for the round of resilience and observability work landing this week.

Skywire Development Update — May 8, 2026

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

Today is a turning point. Two large arcs land on the same day: Kademlia DHT is removed from the codebase, and the deployment services migrate onto a shared pkg/services framework that collapses nine deployment containers into one for CI e2e.

Skywire: DHT Removed — CXO + HTTP Discovery Wins

2459 chore: remove the Kademlia DHT subsystem in favor of CXO + HTTP discovery — the DHT shipped in late April was a sincere attempt at decentralized discovery. Two weeks of running it in production surfaced enough operational sharp edges (value-size limits, signature collision dedup, the difference between DHT and HTTP being a constant source of “which one is right” questions) that the project chose the simpler CXO-publisher / CXO-subscriber model instead.

Skywire Discovery: From DHT to CXO + HTTP

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

Two weeks ago we shipped a Kademlia DHT as the decentralized discovery layer for Skywire — TPD, SD, and dmsg-discovery mirrored their authoritative data into it, visors could read from it as an alternative to HTTP, and the dmsg-servers ran full DHT nodes. The vision was that production services would gradually transition to bootstrapping points while the DHT carried the real load.

Today we’re removing the DHT.

The replacement isn’t a step back to centralized HTTP. It’s a different decentralization model — CXO publishers and subscribers — that turns out to fit Skywire’s actual needs much better than a Kademlia DHT.

Skywire Development Update — May 7, 2026

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

Skywire: DMSG Self-Deadlock Fixes Under dmsgfirst Path

The dmsgfirst client introduced yesterday (PR #2433) surfaced a class of self-deadlocks in dmsg-discovery code paths. When a visor’s dmsg disc client runs over dmsg (instead of HTTP), and that client tries to fetch its own entry — or fetch an entry it needs to complete its own connect — the recursive call pattern can deadlock on the dmsg session lock.

Four PRs land on the same day to plug them all:

Skywire Development Update — May 6, 2026

Wed, 06 May 2026 00:00:00 +0000

Skywire: dmsg-discovery — dmsgfirst APIClient

PR #2433 introduces a new shape for the discovery client: try dmsg first, fall back to HTTP. Pre-fix, every discovery client opened an HTTP connection over the clearnet TCP transport; visors behind aggressive firewalls but reachable over dmsg had to manually configure HTTP through a SOCKS5 proxy.

dmsgfirst.NewAPIClient wraps any of the discovery client interfaces. The first request tries the dmsg-http path (using the existing dmsghttp transport); if dmsg isn’t ready or the request fails with a transport-layer error, it falls back to plain HTTP. The fallback is sticky for the duration of the process — once HTTP wins, subsequent requests go straight to HTTP — so we don’t pay the dmsg-handshake cost on every call when dmsg is known-unreachable.

Skywire Development Update — May 4, 2026

Mon, 04 May 2026 00:00:00 +0000

Skywire: Transport Uptime — CXO-Driven Heartbeats

PR #2426 rewrites the transport uptime model from polled re-registration to event-driven heartbeats with slot-accurate timelines.

Pre-fix: TPD inferred uptime from the timing of register/deregister and the 90-second TTL refresh. A transport that was up but lost its refresh window (slow network, brief TPD outage) showed up as “down” until the next refresh succeeded. The bitmap timeline had 90-second resolution and lots of false negatives.

Skywire Development Update — May 3, 2026

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

Skywire: TPD Panic Loop — Two Sources

Production TPD was restarting every 30-40s (RestartCount 556 over 6h on the prod host) because two distinct panics tear down the process. Today’s PRs catch both, plus the residual nil-deref races they exposed.

80fef7159 Fix tpd panic loop: cxo Finc-to-negative + httputil short-write discriminator

pkg/cxo/skyobject/cache.go (*Cache).Finc:1189,1216 — panic: "Finc to negative for: <hash>". The filling-refcount went below zero, likely a duplicate Finc on a Filler.incs map or an Inc/Finc mismatch across overlapping fillers. Hard process kill via panic. Filler.apply / Filler.reject already consume Finc’s error return and just log; surface the inconsistency through that path instead. Clamp fc to 0, log the condition with key and the offending inc, and continue. Worst case is a leaked filling-item slot — orders of magnitude better than killing the service.

Skywire Development Update — May 2, 2026

Sat, 02 May 2026 00:00:00 +0000

Skywire: Forwarded Ports — Arbitrary Targets

546730da6 Forwarded ports/arbitrary target (PR #2405) — raw-TCP forwarding for non-port-80 entries was hardcoded to localhost:<localPort>. Now honors fp.ProxyAddr at both the DMSG forwarder (api_network.go) and the skynet sky-forwarding side (init_services.go) so users can forward an arbitrary host:port (e.g. a LAN service at 192.168.1.20:5432) over .skynet / .dmsg without running it on the visor.

CLI:

skywire cli serve add <p> --to host:port now accepts non-localhost hosts on every port (was rejected outside port 80).
skywire cli skynet port add --proxy-addr help text updated to reflect the broader meaning.

UI:

Skywire Development Update — May 1, 2026

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

Skywire: Per-Transport Latency End-to-End

PR #2401 plumbs measured latency through every layer that touches a transport:

Visor → TPD — the visor’s transport-level ping result (the new mechanism from PR #2317 that replaced RSN-based latency) is included in the transport register call. TPD persists the latency on the entry alongside type, label, and timing.

TPD storage — latency lives in the transport entry, queryable via the GET /transports/edge:{pk} endpoint and surfaced through the DHT mirror.

Skywire Development Update — April 30, 2026

Thu, 30 Apr 2026 00:00:00 +0000

Skywire: DHT Address Mirror + Self-Publish

PR #2399 adds two pieces that close the loop on what visors can do over the DHT directly, without dmsg-discovery as a write path.

Self-publish — every visor now mirrors its own DMSG entry into the DHT on the same cadence the dmsg-discovery sees in HTTP. The DHT target is SHA256(visorPK || “client”), the value is the full signed dmsg entry. A peer that wants to dial a visor can look up the entry from the DHT just like it would from dmsg-discovery — same shape, same signature verification.

Skywire Development Update — April 29, 2026

Wed, 29 Apr 2026 00:00:00 +0000

Skywire: Per-Port PK Whitelist on Raw-TCP Skynet and DMSG

PR #2395 closes a gap in the forwarded-port access-control model. The ForwardedPort.Whitelist field already gated the port-80 HTTP reverse-proxy path (added with the landing page in PR #2317), but raw-TCP forwards on every other port bypassed the check entirely — any peer who knew the port could connect.

The fix:

serve command’s TCP forwarder (skynet path) consults the per-port whitelist before accepting an incoming connection. Source PK comes from the route group’s remote address.
DMSG-side raw-TCP forwarder does the same lookup on its incoming dmsg streams.
Reject path closes the conn immediately; no error frame, no acknowledgment that a port-with-this-number exists. From the rejected peer’s perspective, the port behaves identically to one that isn’t forwarded.

The CLI gains serve whitelist to manage the per-port set:

Skychat Pairing: End-to-End Encryption + Consent

Tue, 28 Apr 2026 00:00:00 +0000

Skychat — Skywire’s built-in messaging app — had been a “best-effort” DM system since it shipped. Any peer who knew your public key could open a chat-app stream to you and send a message. Bodies traveled in cleartext on the wire (over Noise-encrypted transports, but with no app-layer secret of their own), and there was no mechanism to refuse a sender ahead of time. Today’s PR stack changes both of those: consent-gated pairing, plus end-to-end encrypted message bodies that the transport layer never sees in plaintext.

Skywire Development Update — April 28, 2026

Tue, 28 Apr 2026 00:00:00 +0000

The biggest day for skychat: a five-PR stack that turns the chat app from “anyone with my PK can DM me” into a consent-based, end-to-end encrypted system.

2379 per-pair feed primitives + bolt store — each accepted pairing gets its own CXO feed, indexed in a local bbolt store. The pair record carries the peer PK, the negotiated symmetric key, and an Accepted | Declined | Pending state.

Skywire Development Update — April 27, 2026

Mon, 27 Apr 2026 00:00:00 +0000

Skywire: Visor Self-Tracking Telemetry on CXO TreeStore

PR #2359 moves per-visor telemetry off HTTP entirely and onto the CXO TreeStore. Every visor publishes its own self-tracking record — uptime, version, transport count, last seen — into a CXO feed it owns. The transport discovery becomes a CXO subscriber that aggregates the published feeds into the same shape the HTTP /uptimes API used to serve directly.

The payoff is twofold. First, telemetry no longer rides the HTTP TPD register path, so a slow or partitioned TPD doesn’t lose telemetry — visors keep publishing into their local CXO node and the aggregator catches up when reachable. Second, the aggregation is now pull-based instead of push-based: TPD reads from the canonical source (each visor’s own feed) rather than trusting whatever the HTTP register endpoint last accepted.

Skywire Development Update — April 26, 2026

Sun, 26 Apr 2026 00:00:00 +0000

Skywire: DHT Sequence Monotonicity Fix

d6732e3ea Fix DHT seq + self-probe endpoint — two unrelated bugs surfacing in the same PR.

The visor’s dhtPublishLoop seeded seq from the local in-memory store (which starts at 1 after restart), and the tpd_adapter computed seq from entry count + cumulative transport bandwidth (which resets on restart and drops on transport churn). Both produced non-monotonic seq values across visor restarts. DHT peers correctly rejected those Put operations with ErrSeqNotMonotonic, manifesting as repeated 'PutValue failed: dht: remote rejected put: dht: sequence number must increase' debug logs after every visor restart.

Skywire Development Update — April 25, 2026

Sat, 25 Apr 2026 00:00:00 +0000

Skywire: Production Performance Push

A run of profile-driven optimizations targeting the deployment services. Every change came from a specific pprof or production-redis observation.

5e9044141 Setup-node porter watchdog — standalone Node.Serve was missing the SweepStalePorterEntries loop the embedded RSN already runs. Production saw ~13 ports/min leaking, full ephemeral exhaustion (16,387 ports reserved) after ~20h of uptime, and ~1 GB of stranded yamux.Stream objects parented by the porter map. Adds the same 60s sweep that drops entries older than 5 minutes.

Skywire Development Update — April 24, 2026

Fri, 24 Apr 2026 00:00:00 +0000

Skywire: DHT Mirror — Full Transport Lists Per Edge

PR #2334 fixes a fundamental flaw in how the transport discovery mirrored data to the DHT:

The problem: TPD’s DHT mirror wrote one MutableItem per transport per edge, keyed by SHA256(edgePK || “tp”). Because multiple transports sharing the same edge resolved to the same target, each Mirror call overwrote the previous one. A visor that was an edge of 552 transports ended up with exactly 1 transport visible under its DHT target. Verified against production: 4,615 transports in HTTP discovery produced only 1,370 DHT items.

Skywire DHT: Decentralizing the Discovery Layer

Fri, 24 Apr 2026 00:00:00 +0000

Skywire has always depended on centralized HTTP discovery services. When a visor wants to find another visor’s DMSG servers, it queries dmsg-discovery. When it wants to know what transports are available, it queries transport-discovery. When it wants to find a VPN or proxy, service-discovery. These services are reliable and fast, but they’re single points of failure and they concentrate load on the deployment operator.

Over the past week, we’ve been building and deploying a Kademlia DHT that will gradually replace these centralized services with peer-to-peer discovery. The production deployment is transitioning from the source of truth to a bootstrapping point and network observer.

Skynet: Port Forwarding, Website Hosting, and Direct Transport

Thu, 23 Apr 2026 00:00:00 +0000

Over the past two weeks, Skynet went from a name and a concept to a working system. Every visor in the Skywire network can now host services — websites, APIs, custom applications — accessible to any other visor over the encrypted mesh, with no port forwarding on the router, no public IP address, and no DNS configuration.

What Skynet Is

Skynet is Skywire’s application-layer port forwarding system. It lets a visor expose local TCP ports to the network, accessible via .skynet domains through a resolving proxy. Think of it as a decentralized reverse proxy where the “internet” is the Skywire mesh.

Skywire Development Update — April 23, 2026

Thu, 23 Apr 2026 00:00:00 +0000

Skywire: Skynet Direct Transport

PR #2331 introduces the most significant optimization for skynet: direct transport forwarding bypasses route setup entirely.

For visors that share a direct transport (STCPR or SUDPH), skynet port forwarding now uses VStreamMux on route ID 0 with SkynetForwardPacket type. No route setup node involved. No route descriptor conflicts. No ephemeral port exhaustion.

How it works:

The skynetweb dialer checks if a direct transport exists to the destination PK
If yes: opens a VStream directly over the transport (route ID 0)
If no: falls back to DialRoutes for multi-hop connections through the DMSG mesh

The forwarding server accepts connections from both paths — route groups (existing) and VStream mux (new) — using the same handleServerConn handler. The ready byte, ClientMsg handshake, and port dispatch are identical.

Skywire Development Update — April 22, 2026

Wed, 22 Apr 2026 00:00:00 +0000

Skywire: DHT-to-Discovery Pusher

PR #2327/2328 closes the loop on DHT architecture: DMSG servers now push DHT writes back to the HTTP discovery services, enabling a smooth transition where visors can publish to the DHT only while the HTTP APIs stay in sync.

Store.SetOnPut callback — fires after every successful DHT store operation (outside the lock). The DMSG server registers a callback that inspects the salt and forwards the entry to the appropriate HTTP discovery.

Skywire Development Update — April 21, 2026

Tue, 21 Apr 2026 00:00:00 +0000

Skywire: DHT Full Node Discovery and Bulk Sync

PR #2321 adds the infrastructure for DHT nodes to find each other and synchronize their data stores:

GetItems RPC (method 5) — new DHT RPC for bulk data sync. Supports salt filtering (dmsg, tp, svc) and sequence threshold for incremental sync. Paginated with limit + hasMore indicator. 30-second timeout for bulk transfers.

Full node advertisement — full nodes publish their PK under salt “fullnode” every 5 minutes. FindFullNodes() returns bootstrap peers as known full nodes. This lets any visor discover which peers have the complete dataset.

Skywire Development Update — April 20, 2026

Mon, 20 Apr 2026 00:00:00 +0000

Skywire: DHT Arrives — Kademlia Implementation

The biggest architectural change in Skywire since the DMSG merge: a full Kademlia DHT implementation that will replace the centralized HTTP discovery services. PR #2318 introduces the DHT in three phases.

Phase 1: Core DHT Implementation (`pkg/dht`)

A complete Kademlia DHT with BEP44 mutable data support, built from scratch:

id.go — 256-bit NodeID derived from SHA256 of the secp256k1 public key. XOR distance metric for routing decisions.
bucket.go — k-buckets (k=20) with a 256-bucket routing table. Standard Kademlia eviction: least-recently-seen evicted on full bucket, ping-first for live nodes.
item.go — MutableItem with secp256k1 sign/verify (using Skywire’s existing cipher.SignPayload/VerifyPubKeySignedPayload). Monotonic sequence numbers prevent replay.
store.go — thread-safe item store with TTL expiry and capacity eviction. Items are keyed by SHA256(pubkey || salt), allowing multiple namespaces per identity.
rpc.go — length-prefixed JSON wire protocol: Ping, FindNode, GetValue, PutValue.
lookup.go — iterative Kademlia lookup with alpha=3 concurrency. Standard approach: query closest-known nodes, refine until convergence.
dht.go — Node type with Put/Get, bootstrap, maintenance loop.
mock_transport.go — in-process net.Pipe network for unit testing.

Phase 2: DMSG Transport and Visor Integration

dmsg_transport.go — DHT transport over DMSG streams on port 100. Reuses existing DMSG sessions, so DHT adds zero new connections.
init_dht.go — visor init module: starts DHT after DMSG is ready.
api_dht.go — DHTStatus/DHTPut/DHTGet visor API methods.
DHTConfig in visor config: enable, bootstrap_pks, full_node flag.

Phase 3: Discovery Adapter and Hybrid Client

disc_adapter.go — implements the existing disc.APIClient interface backed by DHT. Entry/PostEntry/PutEntry/DelEntry map to DHT Get/Put with salt=“dmsg”. Server entries are auto-cached on fetch. StartReannounce keeps entries alive beyond TTL.
disc_hybrid.go — DHT-first with HTTP fallback. Reads try DHT first, fall back to HTTP on miss. Writes dual-write to both DHT and HTTP. Bulk queries delegate to HTTP (until DHT population is sufficient).

Skywire: DHT Full Node on DMSG Servers

PR #2319 takes the DHT from “implemented” to “deployed”:

Skywire Development Update — April 17, 2026

Fri, 17 Apr 2026 00:00:00 +0000

Skywire: Network Stability — Skynet, Transport-Level Ping, Website Hosting

PR #2317 is another massive change touching nearly every subsystem. The theme: making Skywire a practical platform for hosting and accessing services.

Skynet Port Forwarding

The forwarded port system was built from the ground up:

Rich metadata model — ForwardedPort replaces the simple map[int]bool with per-port metadata: label, description, show-on-landing toggle, skynet/DMSG forwarding toggles, PK whitelist, and proxy address. Data persists to local/forwarded_ports.json across restarts.

Skywire Development Update — April 16, 2026

Thu, 16 Apr 2026 00:00:00 +0000

Skywire: CLI Refactor and Skynet Integration

PR #2313 is one of the largest single changes in recent Skywire history — a complete restructuring of the CLI, a new deployment configuration system, and the foundations of the skynet integration.

CLI Directory Reorganization

The command structure was reorganized for clarity:

cmd/dmsg-commands -> cmd/dmsg — DMSG-specific commands
Services moved to cmd/svc/ — all deployment service binaries
Utilities moved to cmd/util/ — helper tools
cmd/skywirevisormobile removed — dead Android scaffold that was never completed

Cobra command groups introduced across all command trees: skywire cli now has 8 groups (Network, Transports, DMSG, Visor, Services, Utilities, Config, Debug), visor has 5, tp has 3. The flat list of 60+ commands is now navigable.

Skywire Development Update — April 13, 2026

Mon, 13 Apr 2026 00:00:00 +0000

Skywire: DMSG Self-Ping Command

ff684f796 Add skywire dmsg self-ping — a new diagnostic command that verifies end-to-end DMSG connectivity by having the visor dial itself through the DMSG network. The visor dials its own public key on a test port, measures the round-trip time, and reports success or failure. This is the definitive test for “is my visor reachable over DMSG?” — it exercises the full path: discovery lookup, server session, noise handshake, stream establishment.

Skywire Development Update — April 12, 2026

Sun, 12 Apr 2026 00:00:00 +0000

Skywire: Uptime Tracking Overhaul

The uptime system was completely reworked to produce higher-fidelity data and reduce load on the standalone uptime tracker:

0c18f00a9 TPD: record heartbeat on transport registration — every time a visor re-registers its transports (every 90 seconds), the TPD now records a heartbeat for uptime tracking. This piggybacks uptime data collection onto an operation that’s already happening, rather than requiring a separate HTTP call.

0c955313f Visor: send heartbeat to TPD alongside uptime tracker — the visor now sends heartbeats to both the standalone uptime tracker and the TPD, ensuring continuity during the migration.

Skywire Development Update — April 11, 2026

Sat, 11 Apr 2026 00:00:00 +0000

Skywire: Unified Service Mode (pkg/svcmode)

Every deployment service (transport discovery, service discovery, route finder, address resolver, config bootstrapper, uptime tracker) previously had its own copy of HTTP + DMSG listener setup code — a pattern that had diverged across services over months of independent fixes. Today that was replaced with pkg/svcmode: a single shared helper that handles both HTTP and DMSG HTTP listening, health endpoints, and graceful shutdown for all services.

Skywire Development Update — April 10, 2026

Fri, 10 Apr 2026 00:00:00 +0000

Skywire: Services Health Dashboard

be6e5ce05 Services health UI dashboard — the hypervisor now has a dedicated services health page that probes every deployment service (DMSG discovery, transport discovery, service discovery, route finder, uptime tracker, address resolver, DMSG servers) and displays their status, version, public key, transport type, and latency in a table view. Services are probed over DMSG where possible, with HTTP fallback.

1145197ba Fix hypervisor UI feedback items — split the health flags into separate indicators for HTTP and DMSG reachability, so operators can see which transport layer is working when debugging connectivity issues. Also fixed several UI regressions.

Skywire Development Update — April 9, 2026

Thu, 09 Apr 2026 00:00:00 +0000

Skywire: Route Setup Integrated Into DMSG Server

One of the most significant architectural changes this week: route setup-node is now integrated directly into the DMSG server (#6698ccf4).

Before — route setup was a standalone service (skywire svc sn) that visors connected to via DMSG to request route setup. Every setup operation required the visor’s DMSG client to establish a separate stream to the setup node, which in turn might have needed its own stream to reach the destination visor. This created ephemeral port exhaustion issues under load.

Skywire Development Update — April 8, 2026

Wed, 08 Apr 2026 00:00:00 +0000

Skywire: Merge DMSG Into Skywire

A structural change that had been brewing for weeks: the DMSG library was merged directly into the Skywire repository (#2289).

The problem — DMSG and Skywire were separate repositories, and Skywire vendored DMSG as a dependency. Every DMSG fix required:

Commit the fix to the DMSG repo
Tag a new DMSG version
Update the vendor directory in Skywire
Wait for the Skywire CI to pass
Merge the vendor update

This “vendor ping-pong” was consuming significant development time and causing CI reliability issues — tests would fail on one side or the other due to timing mismatches between repos.

Skywire Development Update — April 7, 2026

Tue, 07 Apr 2026 00:00:00 +0000

DMSG: Two More Server Goroutine Leaks

The DMSG server goroutine hunt continued — two more leaks found and fixed, both involving the server’s forwarding logic.

Bridged streams idle timeout (#372) — bridged streams (bidirectional copy between two clients through the server) were blocking forever on io.Copy Read when one side disconnected without cleanly closing the connection. This caused goroutines to accumulate — observed as 55,000+ stuck goroutines in production.

The fix added an idleTimeoutConn wrapper that resets a per-operation deadline on each Read/Write. If no data flows for 5 minutes, the deadline fires, io.Copy returns an error, CopyReadWriteCloser closes both streams, and the goroutine exits. The timeout resets on each successful read/write, so active streams are unaffected — only truly idle/dead streams are cleaned up.

Skywire Development Update — April 6, 2026

Mon, 06 Apr 2026 00:00:00 +0000

Skywire: Setup-Node Goroutine Leak Fix

Route setup-node goroutine leak (#2280) — a serious production issue: the setup-node was accumulating 500+ leaked goroutines within minutes of restart.

Root cause — MakeMap used an unbuffered results channel, causing goroutines to block forever on send when the reader stopped after the first error. Combined with no dial timeout, unreachable visors caused indefinite blocking in DialStream.readResponse.

The fix — added buffered channels and explicit dial/handler timeouts so stuck dials can’t accumulate. The setup-node now cleanly errors out and cleans up goroutines when it can’t reach a visor.

Skywire Development Update — April 5, 2026

Sun, 05 Apr 2026 00:00:00 +0000

Skywire: CI E2E Fixes and Runtime Hypervisor Toggle

A consolidation day focused on test reliability and configuration ergonomics (#2279).

-Q flag: write conf template to file — a new -Q flag writes the conf template to a specified file path. Both -q (print) and -Q (write) now reflect flags passed to them: skywire cli config gen -iq uncomments ISHYPERVISOR in the printed output. The new applyFlagsToConf helper maps CLI flags to SKYENV variables so they take effect in the generated config.

Skywire Development Update — April 4, 2026

Sat, 04 Apr 2026 00:00:00 +0000

Skywire: Regional Saturation Scaling for Rewards

A significant economic change to the reward system: regional saturation scaling (#2278).

The problem — the presence pool distributes rewards equally across all uptime-eligible visors. If a single country has 1,000 visors, it receives 1,000 shares. This creates an incentive to flood a single region with cheap VPS instances to maximize reward extraction, which distorts the geographic distribution of the network.

The fix — apply diminishing returns to the presence pool based on unique IP addresses per country. Countries with more unique IPs still receive a larger total allocation, but each additional IP contributes less. Default is square-root scaling (configurable via --sat-exp flag). A country with 100 IPs gets sqrt(100) = 10 units of weight per IP instead of 1 per IP; a country with 4 IPs gets sqrt(4) = 2 units per IP — so the 100-IP country gets 5× the weight of the 4-IP country, not 25×.

Skywire Development Update — April 3, 2026

Fri, 03 Apr 2026 00:00:00 +0000

Skywire: SKYDEPLOY Override

New environment variable (#2276) — SKYDEPLOY=/path/to/config.json overrides the embedded services-config.json deployment configuration. This supports:

Private networks — point Skywire at a custom deployment without rebuilding
Corporate deployments — run a private Skywire network with your own TPD, DMSG, Address Resolver, etc.
Testing — quickly switch between test and production deployments

The embedded config is still used as the default, so nothing changes for users on the public network. But operators running private deployments no longer need to patch and rebuild Skywire to change the discovery URLs.

Skywire Development Update — April 2, 2026

Thu, 02 Apr 2026 00:00:00 +0000

Skywire: DMSG gRPC Listener

A new remote-management capability: DMSG gRPC listener for remote gotop and stats (#2271).

Design — a new DmsgGRPCPort (49) serves gRPC over DMSG alongside the existing local CLI gRPC. The DialDmsgRPC function was updated to dial the new port instead of DmsgHypervisorPort. This enables:

Remote gotop (system activity monitor) over DMSG
Stats streaming from any visor to any other visor
Ping and latency measurements between visors

Both visors need the update — the local visor dials the new port and the remote visor listens on it. Once deployed, operators can run skywire cli visor ping or stream system activity from any visor they have authorized access to, all over the encrypted DMSG overlay.

Skywire Development Update — April 1, 2026

Wed, 01 Apr 2026 00:00:00 +0000

Skycoin: Explorer Fixes for Fibercoin Support

Explorer blocks page fix — the explorer’s blocks page was showing “Error loading data” silently. The root cause was that getBlocks was being called without the verbose=1 parameter, so transaction inputs were returned as bare UXID strings instead of objects with owner/coins/hours fields. The frontend’s parseGenericTransaction would fail silently on the bare strings. Fixed by adding verbose=1 to the API call.

Content-Type header ordering — a subtle bug in the explorer proxy: Content-Type was being set after WriteHeader, so the header was never actually sent to clients. Fixed to set Content-Type before WriteHeader.

Skywire Development Update — March 31, 2026

Tue, 31 Mar 2026 00:00:00 +0000

Skywire: Xpub Address Reuse Fix

Subtle bug in the reward system’s BIP44 address handling (#2266): resolveRewardAddress was deriving addresses from the visor’s xpub key by day count, but on days where reward distribution was delayed (no {date}.txt transaction marker), the next successful distribution would reuse the same derived address from the previous period.

The fix — resolveRewardAddress now offsets the BIP44 derivation index by the number of consecutive undistributed days. If rewards are delayed by 3 days, the address for the next distribution is derived 3 indices ahead of where it would have been, preventing reuse.

Skywire Development Update — March 30, 2026

Mon, 30 Mar 2026 00:00:00 +0000

Skywire: LAN DMSG Auto-Discovery

Major improvements to the LAN DMSG server feature from earlier in the week:

Port 0 support — the OS now auto-selects an available port for the LAN DMSG server. The LAN IP is detected automatically from private network interfaces. No manual port configuration needed.

Keypair stored in visor config — instead of requiring a separate key file, the PK/SK fields are now in LANDmsgServerConf directly. Auto-generated on first use and persisted via the existing config flush mechanism.

Skywire Development Update — March 29, 2026

Sun, 29 Mar 2026 00:00:00 +0000

Skywire: LAN DMSG Server Polish and Hypervisor UI Fix

A consolidation day following the LAN DMSG server work from March 28. PR #2264 (“Fix/next”) bundled the LAN DMSG server implementation together with the hypervisor UI CPU spike fix into a single merge.

Recap of the LAN DMSG server — the hypervisor can now run a private DMSG server on the LAN. Visors connect to it preferentially for local communication, avoiding round-trips through public relay servers. Zero configuration for the hypervisor (enable: true), and the server uses direct.NewClient for in-memory discovery so it’s never registered publicly.

Skywire Development Update — March 28, 2026

Sat, 28 Mar 2026 00:00:00 +0000

Skywire: LAN DMSG Server in the Hypervisor

A clever optimization for LAN-based Skywire deployments: the hypervisor can now run an embedded DMSG server on the local network. LAN visors connect to it preferentially instead of routing all their DMSG traffic through public relay servers on the internet.

How it works — the hypervisor starts a private DMSG server on the LAN with a persisted keypair. It uses direct.NewClient for in-memory discovery (no public registration with the DMSG Discovery). A GET /api/lan-dmsg-server endpoint exposes the server’s public key and address for auto-discovery by LAN visors. A lanPriorityDisc wrapper prepends the LAN server entries to discovery results, so visors connect to it before trying public servers.

Skywire Development Update — March 27, 2026

Fri, 27 Mar 2026 00:00:00 +0000

Skycoin: BIP44 Wallet UX Overhaul

A major UX improvement day for the wallet GUIs:

xpub key display — account-level extended public keys are now exposed in both the API and both wallet GUIs (desktop and web). Users can see and copy their account xpub for watch-only wallet setups or sharing with accounting tools.

Address hierarchy — BIP44 wallet addresses are now displayed nested under their parent xpub key, with BIP44 child indices shown and path labels (e.g., m/44'/8000'/0'/0/3) on each address section. This makes the HD wallet structure visible and understandable instead of showing a flat list of addresses.

Skywire Development Update — March 26, 2026

Thu, 26 Mar 2026 00:00:00 +0000

DMSG: Server CPU Exhaustion Fix

The root cause of DMSG server performance issues was found and fixed:

Stream concurrency limit — a single DMSG session (e.g., from a setup node) could spawn unbounded goroutines via stream creation, starving the server’s CPU. A per-session concurrency semaphore (2048 streams) now provides backpressure — streams exceeding the limit are immediately closed rather than queued (#353).

Accept loop backoff — non-fatal stream accept errors were causing tight CPU spin loops. A 50ms backoff delay was added on persistent errors.

Skywire Development Update — March 25, 2026

Wed, 25 Mar 2026 00:00:00 +0000

CXO-based transport discovery over DMSG — a CXO DMSG transport adapter was added, allowing CXO nodes to communicate over DMSG instead of raw TCP. This is the foundation for distributing transport discovery data through CXO’s content-addressable object system over the encrypted DMSG overlay — a step toward decentralizing the TPD (#2249).

Login chain genesis — the first steps of a Fibercoin-based login chain for the reward system were implemented. The login chain is a dedicated Fibercoin blockchain used to authenticate reward claims. Genesis block signing was implemented (#2250).

Skywire Development Update — March 24, 2026

Tue, 24 Mar 2026 00:00:00 +0000

Skycoin: pprof for Explorer and Web Wallet

Profiling support — --pprofmode and --pprofaddr flags were added to both the blockchain explorer and skycoin web. Combined with the DMSG pprof flags added yesterday, every long-running Skycoin and DMSG service can now be profiled at runtime. This reflects an ongoing effort to diagnose and eliminate performance bottlenecks across the stack.

Skywire: Dependency Updates and gotop Fix

Dependency updates — Go module dependencies were updated across the board.

Skywire Development Update — March 23, 2026

Mon, 23 Mar 2026 00:00:00 +0000

Skycoin: Release Documentation and Windows MSI

RELEASE.md — a new document was added describing all release binaries, their contents, and the build process. This makes the release pipeline auditable and helps new contributors understand what gets shipped.

Windows MSI installer — skyhw.exe and its required DLLs are now correctly included in the Windows amd64 MSI installer.

Skywire: RWMutex Deadlock and KCP Leak

Two stability-critical bugs were found and fixed:

RWMutex deadlock in ActiveRoutes — the ActiveRoutes RPC call was taking an RLock on a mutex, then calling a function that attempted a full Lock on the same mutex. This caused the visor’s RPC interface to hang permanently, making it unresponsive to all CLI commands. Discovered because skywire cli tp would freeze (#2243).

Skywire Development Update — March 22, 2026

Sun, 22 Mar 2026 00:00:00 +0000

Skycoin: Code Quality and Windows Release

A cleanup and hardening day following the v0.28.4 push.

Internal package restructuring — the internal/ directory was eliminated. The chacha20 package was moved up to a public location and fuzz packages were renamed. This removes Go’s internal/ import restrictions, making these packages available for use by the Skywire vendor and other dependents.

Cyclomatic complexity reduction — three functions that had grown unwieldy were refactored: serve(), postProcess(), and addressGenCmd(). Each was broken into smaller, testable functions.

Skywire Development Update — March 21, 2026

Sat, 21 Mar 2026 00:00:00 +0000

Skycoin: Dynamic Fibercoin Branding and v0.28.4

The final push for Skycoin v0.28.4:

Dynamic ASCII art for all help menus — setting FIBER_TOML now makes every help menu (skycoin, skycoin daemon, skycoin cli, skycoin web, skycoin explorer) display the configured coin’s name in ASCII art. The daemon description, CLI defaults (RPC_ADDR, COIN, DATA_DIR), and web wallet branding all adapt automatically. A cli halt command was added for graceful daemon shutdown (#2825).

Skywire Development Update — March 20, 2026

Fri, 20 Mar 2026 00:00:00 +0000

Skycoin: Newcoin Templates and Fibercoin Tooling

newcoin templates subcommand — the embedded code generation templates can now be printed to stdout with skycoin newcoin templates, so users can inspect, customize, and feed them back with --template-dir. The --template-dir flag, which was previously dead code, now actually works to override the embedded templates (#2821).

fiber.toml defaults — noisy peer connection log messages were suppressed, and fiber.toml default values were updated to be more useful out of the box.

Skywire Development Update — March 19, 2026

Thu, 19 Mar 2026 00:00:00 +0000

Skycoin: BIP44 Chain Selection and Release Build Fixes

BIP44 chain selection — the API, CLI, and web wallet GUI now support selecting different BIP44 derivation chains (external vs. internal/change addresses). This gives users more control over address generation for privacy-conscious workflows — change addresses can be generated separately from receiving addresses, matching standard Bitcoin wallet behavior (#2817).

Release build hardening — the cmd/release binary (which includes hardware wallet support via libusb/cgo) was fixed to compile correctly on platforms where cgo is available and degrade gracefully where it isn’t. The DisallowUnknownFields restriction was removed from the API client JSON decoder, which was causing failures when the API returned fields the client didn’t expect — a forward-compatibility issue that would break older clients talking to newer nodes (#2820).

Skywire Development Update — March 18, 2026

Wed, 18 Mar 2026 00:00:00 +0000

Skycoin: BIP32 Panic Fixes and Fibercoin CI

BIP32 panic-to-error conversion — the bip32 package used log.Panic for error conditions, which would crash the entire process on invalid xpub keys or derivation failures. These were converted to proper error returns so callers can handle them gracefully. New verifyXpub and nextAddress CLI commands were added for xpub key validation and unused address derivation.

Fibercoin genesis CI test — an integration test was added that creates a Fibercoin from scratch in CI: generates a genesis wallet, creates a fiber.toml, starts a daemon, creates the genesis block, distributes coins, and verifies the chain state. This catches regressions in the Fibercoin creation workflow automatically.

Skywire Development Update — March 17, 2026

Tue, 17 Mar 2026 00:00:00 +0000

Happy Birthday, Skycoin Blockchain

Eleven years ago today — March 17, 2015 — the Skycoin genesis block was created. The chain has been running continuously ever since, through organizational splits, team changes, and complete codebase rewrites. Block 194,634 and counting.

Skycoin: Web Wallet Hardening

A dense day of web wallet improvements:

BIP44 account support — the desktop wallet (skycoin-web) now properly supports BIP44 multi-account structure with encrypted seed storage. The beforeunload handler was fixed to prevent accidental data loss.

Skywire Development Update — March 16, 2026

Mon, 16 Mar 2026 00:00:00 +0000

Skycoin: Bitcoin Wallet Support Lands

The biggest feature addition to Skycoin in years landed today: full Bitcoin wallet support in the skycoin web thin client.

Bitcoin via Electrum and Bitcoin Core — two new backend types were added to the web wallet: an Electrum client (TCP/TLS) and a Bitcoin Core RPC client. Both support UTXO fetching, balance queries, transaction history, fee estimation, and broadcast (#2815 baseline, with Bitcoin-specific code in this commit).

Skywire Development Update — March 15, 2026

Sun, 15 Mar 2026 00:00:00 +0000

Skywire: Docker and CI Overhaul

Today’s work focused on fixing the Skywire Docker build and deployment pipeline and upgrading the frontend stack.

Docker build fixes — the Docker build was broken by several issues: the +dirty version suffix appeared in image tags because the build context had uncommitted changes, the go sum database check for the Skywire module was failing in containers, git was missing from the Docker image (needed for GOPROXY=direct), and ldflags were being passed to Docker targets that don’t support them. All four issues were fixed across PRs #2215–#2218.

Latest Version of Skycoin Desktop Wallet Adds Skywallet Compatibility

Mon, 02 Dec 2019 17:00:00 +0000

The latest version of the Skycoin desktop wallet and daemon is now available for download at Skycoin.com/downloads. The new release, version 0.27.0, adds support for the recently released Skywallet.

At the end of November, the Skycoin community saw the successful launch of the highly anticipated Skywallet, a portable hardware cryptocurrency wallet designed by Skycoin. The Skywallet is able to securely generate a wallet seed without connecting to the Internet or a computer. Users can send Skycoin to the address generated from the secure seed without fear that the seed is compromised.

July 2019 Community Update

Thu, 08 Aug 2019 00:00:00 +0000

As always, the Skycoin team continued to deliver regardless of market fluctuations and general Cryptosphere craziness. July saw a flurry of activity across the board as Skycoin closes in on realizing a vision of true decentralization.

Skycoin remained a high flier on coincodecap.com during July with 1216 commits across all the Skycoin repositories, confirming yet again that Skycoin is one of the most active projects in the space.

![Skycoin ranked 2nd for Github activity in July](/img/CoinCodeCap.com July.JPG “CoinCodeCap.com July”)

Development Update - Week 30 & 31

Fri, 02 Aug 2019 00:00:00 +0000

Skywire Update

The latest progress on the Skywire meshnet has focused on two key areas, beginning with the improvement of automated tests and addition of new test scenarios. We also introduced a second transport implementation, which as well as being simpler than dmsg is also able to directly connect two nodes. (dmsg will be used for the network’s control plane and the TCP transport in the data plane, as it does not tunnel traffic over an intermediate server.)

Skycoin Development Update - Week 28 & 29

Fri, 19 Jul 2019 00:00:00 +0000

Skywire Update

The past two weeks’ work on Skywire has centered on two main objectives: switching to dmsg and improving the public deployment’s performance, and writing automated integration tests. Both of these are essential to migration; along with a stable, working public deployment, we need automated integration tests that accurately resemble it in order to ensure the code we push doesn’t break the mainnet.

A lot has gone into achieving this:

June 2019 Community Update

Fri, 12 Jul 2019 00:00:00 +0000

June 2019 will go down in history as Skycoin’s #MonthOfAnnouncements, and, what a month it turned out to be! True to form, the Skycoin team brushed aside any distraction and kept delivering throughout the month to ensure that Skycoin’s trajectory to the top remains steady.

Development

The usual flurry of development activity carried on throughout June and Coincodecap.com consistently shows Skycoin among the top 10 projects ranked according to all Github activity. During June, the Skycoin Github saw a massive 963 commits from 21 developers, meaning Skycoin was placed at number 2 out of all projects for the month!

Skycoin Development Update - Week 27

Sat, 06 Jul 2019 00:00:00 +0000

Skycoin Core Update

Over the past week we have been working to redesign the wallet management library to support multiple wallet “types” (a prerequisite for full bip44 wallet support).

Skywire Update

Skywire has now implemented benchmarks for dmsg structures. Meanwhile, we have moved the dmsg library into its own repo and created a wrapper for it in Skywire, as well as increasing test coverage for dmsg. Because we want other services to be able to use dmsg, we have now made it independent of Skywire. As a result, Skywire imports dmsg so that projects using it for communication do not need to import Skywire.

Skycoin Development Update - Week 26

Fri, 28 Jun 2019 00:00:00 +0000

Skycoin Core

The major news this week is the launch of the new Android wallet. Among other updates, it now includes language support for Japanese!

Skywire Update

Skywire has now added at retry logic for application use following network error. We have also fixed certificate issues with public deployments and written more tests for dmsg.

Skywallet Update

As well as adding firmware update functionality for the desktop wallet, Skywallet added a version endpoint to the daemon this week.

Skycoin Development Update - Week 25

Fri, 21 Jun 2019 00:00:00 +0000

Skywire Update

This week Skywire implemented a new shutdown procedure for an app on the Skywire node restart process. We also improved checks for the transport establishment handshake and added profiling for the Skywire node.

Skywallet Update

As well as fixing a number of issues discovered during the last review, Skywallet focused this week on reviewing edge case tests for the signing function.

Coin Hour Bank Update

Coin Hour Bank has now added a comments column in the transaction table, as well as OTP support for withdrawals. We have also fixed the email notification for successful withdrawals, improving user experience.

Skycoin Development Update - Week 24

Fri, 14 Jun 2019 00:00:00 +0000

CX Update

CX added the CX version parameter to CX Program this week, providing a way to handle incompatibilities between the different CX versions that may have been used on CX chains to date. We also solved an issue that was preventing the program state from storing, improving usability.

Whitelisting System Update

The most recent changes to the whitelisting system have resolved an issue that was creating duplicate nodes for users.

Introducing CX v0.7

Thu, 13 Jun 2019 00:00:00 +0000

The Skycoin team keeps on powering through #MonthOfAnnouncements, and delivering key product updates through amazing development progress!

CX version 0.7

CX is the blockchain programming language for smart contracts on the Skycoin blockchain, and is an incredibly powerful part of the Skycoin ecosystem.

CX is a general purpose, interpreted, and compiled programming language, with a very strict type system and a syntax similar to Golang’s. CX provides a new programming paradigm based on the concept of affordances.

Skycoin Development Update - Week 23

Fri, 07 Jun 2019 00:00:00 +0000

CX Update

We have big news to announce this week thanks to the public beta release of CX version 0.7. This version of our programming language integrates it with Skycoin’s Fiber blockchains, enabling developers to write programs that will be stored on blockchains specialized for CX code. It also introduces plenty of new features, language fixes, libraries and bug fixes. Learn more here and check out the tutorial!

May 2019 Community Update

Thu, 06 Jun 2019 00:00:00 +0000

The Skycoin universe experienced a surge of fresh energy during May as the long dark crypto winter started yielding to the spring of the bulls.

Rather than surrendering to the temptation of hibernation during the aforementioned dark months, the Skycoin team and community were hard at work preparing for the inevitable spring thaw.

This month’s update reflects the fruits of that work.

Development

Development went ahead at full steam with the weekly development updates on the Skyblog showing continuous refinement of Skywire, the Skywallet, Ledger integration, CX and the Coin Hour Bank which are all nearing completion or big milestones.

Major June Announcements

Sat, 01 Jun 2019 13:00:00 +0000

The Skycoin community has many reasons to pop the champagne and celebrate!

The Skycoin team is delivering not just one announcement, but multiple announcements for today alone!

#MonthOfAnnouncements

As some of the community may have noticed in our flurry of recent news, today marks the start of Skycoin’s Month of Announcements.

In a continual effort to keep the community up to date on Skycoin’s incredible progress, alongside our weekly development updates:

Buy Skycoin with Desktop Wallet v0.26

Sat, 01 Jun 2019 12:00:00 +0000

The Skycoin team is excited to announce an update to the official Skycoin desktop wallet that allows you to buy Skycoin directly from the Official Desktop Wallet!

This new service is provided by an integration with Swaplab, and makes buying Skycoin even easier, safer and faster by removing the need to register with an exchange!

Start by ensuring you have the most recent version of the Skycoin desktop wallet. Download the latest version, 0.26.0 or higher, from skycoin.com/downloads.

Celebrating Skywire's Testnet Anniversary

Sat, 01 Jun 2019 12:00:00 +0000

After years of development, the Skycoin team launched Skywire with a public testnet, and we are amazed to see the progress to date!

We are very excited to celebrate the 1 year anniversary for the Skywire Testnet today!

The year has flown by, and we are extremely proud of our supportive community that has been growing the Skywire network at an amazing pace.

And to show our appreciation, we are happy to announce:

Skycoin Development Update - Week 21

Fri, 24 May 2019 00:00:00 +0000

CX Update

This week the developers fixed a number of bugs that were causing memory-related issues for CX-Chain programs and further improved the testing process with alterations to CX-Chain parameters (for example with Coin Hour Burn).

Meanwhile, developers will benefit from the integration of a new command to work with: newcoin.

Skywire Update

The latest work on Skywire has focused on a number of important fixes, as well as integration tests for both SSH and the proxy.

Skycoin Development Update - Week 20

Fri, 17 May 2019 00:00:00 +0000

CX Update

The biggest announcement this week is the CX blockchain beta release, kicking off our first CX Labs contest. Check out the news around the contest in the CX Labs Telegram room.

Work on the CX programming language has also seen progress on the installation script, with extensive testing on a new Debian VM. This has helped identify possible reasons for why some users have been having difficulty, from issues installing Golang to conflicts between versions. To deal with these we have now updated the wiki, and work continues on the CX-Chains tutorial. (The examples here are simple, but they work!)

April 2019 Community Update

Tue, 14 May 2019 00:00:00 +0000

Skycoin’s hectic progress flowed over from March to April. Starting with Skywire developer mainnet continuing its refinement, the Coin Hour Bank nearing public release, CX Labs offering developers earning potential via the creation of CX apps, and a collaborative Skycoin team attended the biggest Blockchain Hackathon in the world! Just to mention a few highlights. Read on for the full scoop!

Skywire

We are starting with Skywire, our scalable peer-to-peer mesh network, delivering secure, uncensored, and lightning fast internet access across the globe.

Skycoin Development Update - Week 19

Fri, 10 May 2019 00:00:00 +0000

Skywire Update

This week Skywire has benefited from implementation of a human package that allows us to request user input for a number of actions, including transport creation. We have also started implementation of a new uptime tracker, which will soon replace the previous discovery uptime tracking implementation used for the testnet.

Other work has focused on writing for router package tests and ongoing efforts to refactor the app package.

Skycoin Development Update - Week 18

Fri, 03 May 2019 00:00:00 +0000

Skywire

The main focus of the Skywire development this week was directed at continuing the refactoring of the app package and associated changes in the router module. For that purpose, tests were partially rewritten and new tests were developed to increase coverage. Additionally a configuration generator tool for the local test environment was written.

Skywallet

The team added more Salt sources for the Skywallet to salt entropy generated by the Skywallet. The linter was modified to improve the code quality and legibility. In order to allow external developers to develop with the Skywallet, enhanced contribution guidelines were added to the project and functions were added that allow to check the memory protection status of a Skywallet. More and improved tests were written for the Skywallet Golang interface.

Skycoin Development Update - Week 17

Fri, 26 Apr 2019 00:00:00 +0000

Skywire Update:

This week Skywire has moved toward better organization and simplicity. Key changes include the addition of centralized logging for the local testing environment and migration of the Route Setup Node to the public Skywire repo, simplifying the development process. We have also refactored the app package (with naming updates for improved clarity) and implemented pathfinding logic for the Skywire updater configuration file (much like what is used for the main Skywire repo).

Skycoin at Odyssey Hackathon 2019

Thu, 25 Apr 2019 00:00:00 +0000

Google ‘Odessey Hackathon’ and you will find an event billed as the world’s biggest AI and Blockchain hackathon. In just 3 years Odessey grew from 450 to 1500 participants competing in 11 tracks to solve 20 real-world societal challenges.

For the 2019 challenge, Skycoin partnered with Milvum which is a development house hailing from The Hague and with Hiber, a startup focussed on low cost, low energy communications satellites. Through the partnership, we demonstrated Skywire’s functionality in conjunction with other cutting edge technology.

Skycoin Development Update - Week 16

Fri, 19 Apr 2019 00:00:00 +0000

Skywire Update:

Progress on Skywire this week has mainly focused on important refactorings and simplifications. We deduplicated tests and rewrote unstable tests. We have also removed ACKs from the messaging system, simplifying the implementation.

Among other developments, the node summary endpoint now contains the node IP address and the version of the node. The loop endpoint is finished, and we have started work on exposing the application APIs to the manager. This requires a refactoring of the app package.

The Skycoin Coin Hour Bank

Thu, 18 Apr 2019 00:00:00 +0000

What is the Coin Hour Bank?

Put simply, the Coin Hour Bank is a system that allows you to deposit and transfer Coin Hours, the parallel Skycoin currency. Coin Hours are generated passively for holding Skycoins in your wallet. For a refresher on how this works, read this article about Coin Hours.

How will the Coin Hour Bank work?

Version 1 of the Coin Hour Bank allows you to ‘deposit’ your Coin Hours by sending them from your desktop or mobile wallet to a new address in your Coin Hour Bank account. From there, you can send them to another user without cost. You can also view your balance, see your transaction history and initiate out-of-Bank withdrawals. This is an important milestone in the development of the Skycoin parallel currency.

Skycoin Development Update - Week 15

Fri, 12 Apr 2019 00:00:00 +0000

Skywire

Progress on Skywire continues this week with updated commands, bug fixes (completed and ongoing), and important steps toward a completed UI.

We have now improved the Skywire Command Line interface by refactoring skywire-cli commands into separate groups that identify the services they interact with, rather than having them all grouped under skywire-cli as before. For example, commands that interact with skywire-node will now be grouped under skywire-cli node , and so on.

March 2019 Community Update

Thu, 11 Apr 2019 22:00:00 +0000

March madness is a good description of the sheer volume of high quality development and progress made across the expanding Skycoin ecosystem. Mainnet launch, hardware wallet updates, and a new CX release were the highlights on the software side of activity.

Within the Skyfleet, Drew Macgibbon lead the charge with the Skycoin Rewards Program, resulting in a number of fantastic new articles and videos by a host of first-time contributors. The first of the Skyfleet Projects was also announced - Skycoin integration into BTCPay Server - this is huge! Read on for all the Skycoin happenings in March.

Skycoin Development Update - Week 14

Fri, 05 Apr 2019 00:00:00 +0000

Skywire Update

During the past week, the bulk of the work dedicated to Skywire was focused on the Skywire Manager and on improvements to the network protocol.

Work on the Skywire manager re-commenced with a strong push to complete the login/logout functionality of the manager. Tests were written, run and passed. The login/logout function, critical to the security of the Skywire manager, is now complete and changes have been documented.

Inside The Skywire Mainnet

Wed, 03 Apr 2019 00:00:00 +0000

The New Internet Is Here

After years of development and about ten months of intensive testing on a network of nearly 10,000 nodes spanning the globe, we are happy to announce that the first version of Skywire’s mainnet is now live!

What is Skywire?

Skywire is a decentralized, net-neutral, community-driven mesh internet that is fast and resistant to censorship.

Today’s internet is run, or rather suppressed by an oligopolistic market. Large internet service providers (ISPs) harvest personal information, censor websites, give preferential speeds to certain websites, throttle bandwidth and face very few competitors. This means high bills for you and slow speed.

Skycoin Development Update - Week 13

Fri, 29 Mar 2019 00:00:00 +0000

Skywire Update:

Skywire has seen work on mainly two areas of the project: the Skywire Manager and automated testing.

The Skywire Manager has been picked up again and we have finished the login/logout of the Manager. Users can sign in and use cookies to authenticate themselves when managing their nodes. This is required for security reasons.

The other area where we have made progress is the creation of automated integration tests. Automated integration tests allow us to test the system with multiple services and instances running. So far we have relied on unit tests, which test only a single part, and had to do a lot of manual testing. Automated integration tests using the chat application have been created now and facilitate our work. We have created a development environment with a dockerized node and a docker network, allowing developers to build specific closed-network topologies for testing.

Development Update: Introducing CX v0.6 & 0.6.1

Tue, 19 Mar 2019 00:00:00 +0000

About CX

CX is the programming language for smart contracts on the Skycoin blockchain. CX is a general purpose, interpreted and compiled programming language, with a very strict type system and a syntax similar to Golang. CX provides a new programming paradigm based on the concept of affordances.

CX Version 0.6

2019–01–25

Version 0.6 of CX includes a number of features that were introduced in 0.5, including serialization, callbacks, improved error reporting and many more additions that will be laid out in the 0.6 release of the CX book.

Skywire Mainnet Development Update

Sat, 16 Mar 2019 00:00:00 +0000

The initial launch of Skywire mainnet is here! The coordinated work and development from our team was a massive effort to launch all the components of Skywire mainnet. Skywire consists of multiple components that all need to work together to allow the user to encrypt and successfully route traffic to peers, while still maintaining the ability to use applications on top of Skywire. The launch involved development of the following:

Introducing CXFX: The CX Graphics Library

Mon, 11 Mar 2019 00:00:00 +0000

CXFX’s objective is to facilitate the development of games and applications using CX, allowing developers to focus on building their apps instead of having to write everything from scratch! This is a way to share and factorize knowledge.

At first, CXFX will be a library-only environment, allowing you to access CXFX functionalities from a CX program. The eventual goal is to have something like a WYSIWYG (what you see is what you get) game editor, like Unity.

Announcing PySkycoin, scripting for SkyFiber blockchains

Mon, 14 Jan 2019 00:00:00 +0000

Skyfleet, we are thrilled to announce the most recent version 0.25.0 of PySkycoin, the official Python client library for the Skycoin ecosystem. The library has been under development and testing for about a year. During that time it’s been the key to implement non-trivial numbers of tools and integrations. This article will try to help readers answer some simple questions: What is PySkycoin? Why should I use it?.

In short PySkycoin adds a scripting layer on top of the core Skycoin API’s. Now it is possible to use the Python tools we all love to build all sorts of applications powered by the Skycoin blockchain. This is yet another alternative for empowering the many enthusiasts engaged in the unstoppable expansion of the Skycoin ecosystem. The team is committed to ensuring the continued development of this library as well as its companion suite of open-source development tools, and will be hosting each stable release of these code-bases on the official Skycoin github account. Welcome into the future of cryptocurrencies powered by blockchain!

Skycoin iOS Mobile Wallet Announcement

Thu, 15 Nov 2018 00:00:00 +0000

Skyfleet, we are thrilled to announce the launch of the first official iOS version of our mobile wallet. Now available for download in the Apple iOS App Store!

Download the wallet here: https://www.skycoin.com/downloads/

A functional and secure mobile wallet is essential in the democratization of any peer-to-peer monetary system. The initial Android version of our mobile wallet included the basics and some advanced features from the Desktop wallet. Now iOS users will also be able to take full advantage of the Skycoin Ecosystem from the convenience of their phone or tablet.

Skycoin Development Update #135: Android Mobile Wallet Release

Fri, 17 Aug 2018 00:00:00 +0000

Skyfleet, we are thrilled to announce that the first official Android version of our mobile wallet is now fully ready to be released!

Download the wallet here: https://www.skycoin.com/downloads/

(Android v6.0 “Marshmallow” and above)

A functional and secure mobile wallet is essential in the democratization of any peer-to-peer monetary system. This initial version of our mobile wallet includes all the basic and some advanced features as well.

Basic features such as:

Skycoin Development Update #134: Skycoin Wallet Update

Fri, 27 Jul 2018 00:00:00 +0000

We have an update for the Skycoin wallet! Version 0.24 has been released and is downloadable here. Version 0.24 comes loaded with multiple new features which will assist the Skycoin community to store and transact with SKY & Coin Hours. Among the new features is an advanced spending user interface (UI) consisting of the following features:

April Ecosystem Development Update

Wed, 16 May 2018 00:00:00 +0000

The inaugural Skycoin Ecosystem Conference in Shanghai marked the start of a very successful April for Skycoin as the project goes from strength to strength. The hard-working development team continues to make exciting progress on many different fronts including Skycoin itself, the blockchain collectibles game KittyCash, the CXO software and our dedicated hardware suite.

There were multiple updates and changes made to the internal systems of Skycoin. Issues with Skycoin wallet synchronization and micro-transactions were resolved.

Skycoin Skywire Testnet Is Here!

Tue, 15 May 2018 00:00:00 +0000

Skywire Testnet Going Live May 22nd, 2018

Attention Skyfleet! The anticipation has been building, and we’re happy to announce the Skywire testnet will go live one week from today on May 22nd. This significant milestone for Skycoin will finally allow users to connect to create the new internet and engage in an inexpensive, faster, and more secure online experience.

We are happy to announce the Skywire testnet will go live on May 22nd!

March Skycoin Ecosystem Technical Report

Thu, 05 Apr 2018 00:00:00 +0000

During the month of March, our development teams have made tremendous progress on many projects within the Skycoin ecosystem

Skycoin

Completed command-line interface documentation and overall testing.
Based on BIP21’s Skycoin URIs, “hours” will now be displayed to show the quantity of Coin Hours. For example Skycoin:2hYbwYudg34AjkJJCRVRcMeqSWHUixjkfwY?amount=123.456&hours=70
Using a new logging module to replace the old module to ensure compatibility with future projects.
Completed Skycoin Exchange Integration’s documentation.
Tested the newest Go implementation v1.10.

Skycoin wallet

Released wallet v22. Completed both the front-end and fixed vulnerabilities.
Added a signature to the newest version of wallet in order to proof its authenticity.

KittyCash

KittyCash Verification Service - utilizing email subscription service to verify the customer’s purchase in IKO

Skycoin BBS v5.0 Release Announcement

Mon, 18 Dec 2017 00:00:00 +0000

Skycoin BBS v5.0 has finally been released with many changes under the hood!

Thin Client

The most apparent change of all, is the introduction of the thin client. You can now access Skycoin BBS without setting up a node! Just head to bbs.skycoin.com.

In previous versions, one can only (and should only) access/submit content via a web user interface that is served locally. As this web-interface (and the API that it calls) has direct control over the node itself, and signs content with private keys that are stored in-node (or server-side), it is not appropriate to expose it to the public.

State of the Crypto Market and Development Updates

Sat, 14 Oct 2017 00:00:00 +0000

Q&A

There is no mention of a re-working of the whitepapers. Should this not be a priority so that your marketing that has started has reference material. This is a technical coin and so the documentation needs to be up to date.

Project Focus Update

Wed, 04 Oct 2017 00:00:00 +0000

Mobile Wallet

The Skycoin mobile wallet is done.

https://play.google.com/apps/testing/net.skycoin.mobile

Branding, Design

We are revamping the content pages for the Skycoin website

We have a new logo now.

Bounty program has been up for a month. If anyone wants to make Skycoin videos, check the bounty program in telegram.

Skycoin Branding Kit

Skywire

Skywire is working but is getting a rewrite, to use the skycoin/net networking library.

The dashboard for cluster management (node manager) and global network dashboard is currently under development.

Skycoin BBS v4.1 Release Announcement

Tue, 26 Sep 2017 00:00:00 +0000

Skycoin BBS v4.1 has been released!

Change Log

User interface improvements.
Implemented service discovery (connections to other nodes are now automatically managed).
Improved remote submission of board content (implemented via service discovery).
Simplified process of board creation and hosting.
Improvements to CXO data structure.

The next release will bring about even more exciting features! Watch this space to keep up to date.

Binaries

These are avaliable for 64bit windows, mac and linux.

Skycoin BBS v3.1 Release Announcement

Wed, 06 Sep 2017 00:00:00 +0000

Skycoin BBS v3.1 has finally been released!

Changelog

Updated to use latest CXO.
Reimplemented CXO data structure for easier diff management.
Introduction of a views module for easier implementation of different ways of viewing data.
Implemented exporting/importing boards to/from file.
Initial implementation of following/avoiding users.
Improved UI (Work in progress).
Automatic peer-to-peer relay of boards.

Binaries

These are avaliable for 64bit windows, mac and linux.

Source Code

Avaliable on GitHub.

Skycoin BBS Development Update #2

Thu, 31 Aug 2017 00:00:00 +0000

It’s been a bit more than a month since the release of version 0.1, and 0.2 is soon to be ready!

The changes are the following:

Uses the latest CXO version (peer to peer self-replicating database).
Reimplementation of CXO objects and tree (in preparation for new features).
Introduction to a views module for easy implementation of different ways of “viewing” content.
Initial implementation of user following/avoiding.
Completely revamped UI.

CXO Changes

CXO has been seriously refactored to be faster and more stable. The API has been made to work with hash arrays better - with constant time access, faster replication and the ability to access an element directly with a given hash.

Skywire and Viscript

Tue, 15 Aug 2017 00:00:00 +0000

Introduction

Viscript

Viscript is a cross platform CLI, and application launcher and for cluster management eventually. It is based on signal library as a signal server, so it can manage the signal clients, like node and the components in skywire. It can be run in GUI mode or headless mode.

Viscript GUI Screenshot:

We can add app configurations in the config.yaml file, like the meshnet-socks-server:

 meshnet-socks-server:
 daemon: true
 desc: DESCRIPTION GOES HERE
 path: bin/meshnet/meshnet-run-socks-server
 default_args: []
 help: |
 [1] Text name of app, must be unique
 [2] Node address which app will be talked with. ex 101.202.34.56:9000
 [3] Port which socks server will use for connecting with target host. ex 8000

 Full Example Command:
 start meshnet-socks-server sockssrv0 101.202.34.56:9000 8001

After restart viscript, we can check the applications that can be started by viscript, by command apps.

Skycoin BBS Development Update #1

Sat, 05 Aug 2017 00:00:00 +0000

An Introduction

BBS stands for Bulletin Board System. Although traditional BBS systems are no longer widely used, BBS in the modern era is an icon for social services.

Skycoin BBS is one of the first web applications to be implemented using the skycoin ecosystem. Skycoin attempts to revolutionize the internet; decentralizing it and encrypting protocols by default.

Underlying Skycoin BBS is a peer-to-peer self-replicating database named CXO (part of the Skycoin ecosystem). It features immutable tree structures of Golang objects. All objects are referenced via their hashes alongside defined schemata. Each tree has a root object and signed against a public/private key pair. To update the tree, roots have incremental versions called “sequences”. This design allows for fast, bandwidth efficient data replication.

Skycoin: Introducing the Skyminer

Tue, 13 Jun 2017 00:00:00 +0000

Update:

Comment:

Quote from: hannusolo on June 12, 2017, 07:55:31 PM

Regarding tha subject, how much compute power and memory would these nodes require? I saw the renders on telegram about the proposed hardware node, but I have a mining pc that has a mostly unused cpu and memory, thinking about a little upgrade on this side in the future.

Response:

Many hacking firms, used to take over peoples computers so they could put adware on them or build up a botnet, or do clickfraud to make websites look like they were getting more views than they actually are.

Development Update #131

Tue, 16 May 2017 00:00:00 +0000

Bug Fix:

We found a bug last night, where the node goes into infinite loop when trying to create a new block and transactions on network stopped.

The node was assembling 5 transactions into a block, then failing because two transaction tried to spend the same output. Then failing and waiting a few seconds and then trying again with same result.

The code is now enabled to take the list of pending transactions and add random transactions from the list, one at a time, discarding a transactions which if added to the block, would make the block unexecutable against the current unspent output set.

C2CX Listing and update

Mon, 15 May 2017 00:00:00 +0000

C2CX Skycoin/Bitcoin Order Book

We are trying to get C2CX skycoin volume listed on coinmarket cap and get the APIs implemented.

We are also going to open up the SKY/BTC order book, so Skycoin will not only be pegged to the yuan.

Infographics

We are working on an infographics deck. We will have ~240 infographics and diagrams on various topics, explaining the internals of Skycoin and usage.

These are uncorrected examples with a lot of errors.

Quality Control and Bug Fixes

Wed, 26 Apr 2017 00:00:00 +0000

We are doing misc quality control and major bug fixes now

We fixed a few bugs and path directory issues for the windows non-electron build. There was an error in the packaging script and assets were copied to the wrong path and the executable could not find the assets and server terminated on start.

This should be fixed wallet version 15.

We are hunting down and fixing a transaction prorogation issue, where a small number of TX hashes are not propagating to all nodes because of some race condition. We think it is fixed, but are still testing. We have implemented transaction rebroadcast, but disabled it by default because new state information flag for TX in unconfirmed pool should resolve the issue.

The New Skycoin Wallet Version is Out

Fri, 21 Apr 2017 00:00:00 +0000

New Wallet Version:

Skycoin Wallet version 15 is on the website, which fixes dozens of UI bugs.

Transaction status should be working
There is a combined installer for Windows 32/64 bit now
The windows path issue was fixed
Peer to peer connections and PEX (peer exchange) are enabled now

There is a huge back log of improvements on the wallet we are working through.

We have to decide what we will focus on for the next push

Skycoin Partnerships and Content Revision

Thu, 16 Mar 2017 00:00:00 +0000

Skycoin is finally getting an order book. This took too long.

next exchange upgrade/rewrite skycoin will float against bitcoin

The blog is going to be ready tomorrow and we will start migrating content.

We are going to announce several partnerships with large mainstream institutions, so have to cleanup a bunch of stuff and will migrate anything relevant to blog.

We will put a lot of content on the blog and things we have not revealed yet.

New Skycoin Website is Live

Thu, 09 Mar 2017 00:00:00 +0000

The blockchain explorer is up

http://explorer.skycoin.com

The next generation of the skycoin website is online

http://skycoin.com

Several bug fixes:

Race conditions in networking pool fixed
Blockchain explorer moved from node to golang backend server
Congestion control added in meshnet library
New wallet build etc…
CXO was completely written from scratch and is now half the size and simpler
The CLI interface is battle tested and all the major bugs fixed. Automated deposits and withdrawals are working flawlessly now
Rreenabled peer to peer exchange of peers (PEX) and several improvements, such as only relaying peers that allow incoming connections.
Skycoin now has installer on OSX and Windows. We do not have auto update or anything advanced yet

We are :

Creating a skycoin blog and moving appropriate content there
Creating marketing content and a press kit
Creating our next generation infographic set, revealing more about the project. We need to communicate more clearly and with a message that audience will understand and which they will come away with and be able to transmit or communicate to others. We will have another set of messages for developers/technology focused segment.

We also made a significant mathematical breakthrough on the skycoin economy:

You already receive coin hours for holding Skycoins (holding 10 coins for 1 hour, gives you 10 coin hours). These are used to pay transaction fees right now
We figured out how to make Skycoin and coinhours convertible into tokens exchangeable for networking services
This means we will be able to pay a bandwidth or network services reward to the Skycoin holders
We are still evaluating if we should do this and if it would making holding Skycoin more attractive.

Marketing

We are:

Opening up development community
Starting chatrooms for the development community and skycoin community
Starting a systematic and sustained marketing effort (content creation, internal channels, push to external channels, press kit). This area we have put no effort in to date. This has to be ready, by the time the first applications on our platform launch.

Any technical updates on mesh network and all those exciting topics?

New Skycoin Website Blockchain Explorer

Tue, 21 Feb 2017 00:00:00 +0000

Blockchain explorer almost done. Check github.

github.com/skycoin/skycoin

New website

skycoin.com

Exchange API and automated withdrawals and deposits has been in testing for a few months. Minor bugs fixed.

We are working on “narrative” and explaining the differences between Skycoin and Bitcoin clearly and how the consensus process differs.
Creating a movie to explain the project clearly
Releasing the first applications that users can use and get coins.

The altcoin space is saturated with spam coins and we need to be very clear, concise and have a systematic marketing plan.

Skycoin Status Update

Sat, 28 Jan 2017 00:00:00 +0000

Exhausting list of changes, updates and bug fixes.

Most of the wallet bugs/issues are fixed
The CLI and automated deposits and withdrawals are done, raw transactions, send to many
Continuous improvements to the wallet
Continuous improvements to the website
CLI for meshnet daemon is working (try it)
CLI for CXO daemon is in progress
Designing new, next generation cross platform environment for bundling our applications and daemons

We have more academic papers coming.

Skycoin: Attack of the Bugs 5

Fri, 27 Jan 2017 00:00:00 +0000

We fixed eighty wallet bugs. Look at commits on github.

The CLI is substantially upgraded and automated deposits and withdrawals are working now. Hundreds of changes and improves to the Skycoin CLI interface.

We upgraded to latest version of electron and the copy/paste issues are fixed.

32 bit windows builds should be ready in next release.

We are creating installers for windows and OSX, so that you can install skycoin like a native application.

Skycoin Infographics 2

Sun, 08 Jan 2017 00:00:00 +0000

Infographics

Skycoin Shifting Focus Towards Marketing

Sun, 08 Jan 2017 00:00:00 +0000

Our technicals are done. I think we have fixed the last bugs. The wallet is getting polished up very nicely.

We need to start on marketing, applications, user community:

We need to get blog and need to start getting content
We need to start doing weekly content pushes.
We need to pull in the market people
We need to start doing sequential listings on the major exchanges
We need to push out the first applications on the platform

So I think we are on track to shift focus to marketing soon. Definitely by the time the first two applications are running.

Skycoin Infographics 1

Sun, 25 Dec 2016 00:00:00 +0000

We are at 90% launch readiness:

Network is operating
3 of the 7 white papers are on the websites
Deposits, withdrawals and done
Skycoin order book is done
CLI and WebRPC are done
Skycoin.com website is 70% done (backlog of tickets)
Over half the wallet builds are on website (but have backlog of UI bugs)
Wallet explorer API is done. We are waiting on web dev to fix UI bugs and to do the stand alone blockchain explorer
Infographics are done
Introduction video is in progress
Several of our applications are close to launch (but backlog)

Infographics

Blockchain Explorer Nearing Completion

Tue, 29 Nov 2016 00:00:00 +0000

Blockchain explorer almost working. All of the API functions are in.

Skycoin Social Platform Launch

Wed, 23 Nov 2016 00:00:00 +0000

Summary:

We are launching our own post blockchain social platform. Starting with an immutable object replication system, inspired by Urbit and IPFS. Which is designed for decentralized social networking and source independent networking.

We started this on friday and we almost have a decentralized text only version of 4chan working, five days later.

https://godoc.org/github.com/skycoin/cxo
https://godoc.org/github.com/skycoin/bbs
Each object has a schema and is a struct (with basic set of atomic types)

Skycoin Project Status Update

Fri, 11 Nov 2016 00:00:00 +0000

Coin Status:

Dozens of bug fixes on the CLI and WebRPC interface. The OSX wallet directory bug is fixed now.

I have been using CLI interface a lot.

Meshnet:

Three tasks left then we are onto info graphics and marketing. We do not have a user interface yet but back end will be working.

Marketing:

We are trying to get full time person to manage the social media accounts, marketing and user community.

Command Line Interface Complete

Tue, 08 Nov 2016 00:00:00 +0000

90 commits.

The Command Line Interface is done.
The first version of the WebRPC interface is in the repo

Almost done with check box for floating on exchange.

The CLI in next push will have

Adding private key to wallet by private key hex
Transactions for spending outputs held by a single address by private key
Working send

Community, Website and Skywire Update

Fri, 04 Nov 2016 00:00:00 +0000

Summary:

We need to fix the GUI on the dev branch.
We need to debug the CLI (command line interface, for exchange))
We need to get the WebRPC (for exchanges)

We need to start building out the community.

Need a chat room
Need a forum or BBS
Need a messaging system

We need to get the three white papers done and the website:

Coin / Consensus Paper
Meshnet Paper
Aether Paper

Things we need:

We have to decide if we will float and do the first market internally or use a third party.
We have to get the roadmap up on the website.
We have to create the third version of the website.
We have to get a windows installer (to install under program menu)
We need to do ansible and docker, build/installation automation scripts.

Skycoin Website:

The website is a flat file. No-script (no javascript).

SKY Wallet Update

Thu, 03 Nov 2016 00:00:00 +0000

Wallet Development

The password feature is “wallet encryption”. We are still implementing wallet encryption. Wallet encryption will encrypt your private keys and the seed, so that if the wallet file is stolen, no one can spend your coins, without knowing the password. We are using sha256 + secp256k1hash (very slow on ASIC, GPU, CPU 1000x attempts per second max) for password derivation function and then ChaCha20.

We added a lot of new features to the wallet and have not had time to QA everything.