Skywire

Why it is different

• The address is a key, not a place. A visor makes its own secp256k1 key pair and is reached by the public key, wherever it is. Nobody issues addresses, so there is no account to create, no domain to register and no certificate to buy.
• Reachable behind any router. A visor connects out to relay servers, so it needs no open port. Two visors behind NAT punch through to each other for a direct link, and when no direct link is possible the relay carries the traffic instead.
• Encrypted end to end, through relays too. Every link starts with a Noise handshake that proves both keys and mixes in a post-quantum ML-KEM-768 key exchange. A route through other visors adds a second layer, so the visors in the middle forward packets they cannot read, and each knows only its neighbours. There is no setting that turns encryption off.
• Several paths at once. A connection can be spread over several routes. When one is cut the others carry on, and no single path, and no single visor along it, sees the whole connection.
• One program, everywhere. The visor, its apps, the management tools and the services a network runs on are all one Go program, skywire, under the AGPL-3.0 license. It runs on Linux, Windows and macOS, as an Android app, and as a visor in a browser tab.

What you can do with it

• Use a VPN or a proxy. Send all of a computer's traffic, or one application's, through an exit visor somewhere else. A VPN router can cover a whole LAN.
• Publish a website or a service on your visor's key. It listens only on localhost, and other visors open it by name, with no open port, domain or certificate. SkyDNS makes names like <key>.skynet work in any program on the computer.
• Chat and send mail. Skychat has direct and group messages, voice calls and file sending. Every visor has a mailbox at an address made from its key.
• Reach your own machines. Open a shell, run a command or mount a filesystem on another visor, authenticated by key alone, like SSH without SSH.
• Manage many visors from one dashboard or from the command line, even when they sit behind NAT.
• Run your own network. Every service a Skywire network needs is in the same program, and one command sets up a private network.
• Earn Skycoin for running a visor on the public network. See rewards.

Try it

• In a browser tab, with nothing to install, at skywire.dev. A visor starts in the tab with its own key and joins the same network as every other visor.
• On a computer, from a package or a release on the downloads page, following the install guide. The Android app is on the same page.
• From source, with Go installed:

go run github.com/skycoin/skywire@develop cli config gen -r
go run github.com/skycoin/skywire@develop visor

The visor's dashboard opens at http://127.0.0.1:8000. Watch the network live at status.skywire.dev, and ask in @skywire on Telegram.

How it works

The program that joins the network is called a visor. Visors connect to each other with transports, encrypted links over TCP, UDP, QUIC, WebSocket, WebTransport or WebRTC. On top of transports a visor builds routes, which may pass through other visors. On top of routes it runs apps.

Keys and encryption

A visor's address is its 33-byte public key, written as 66 hex characters or 53 base32 characters. Every transport starts with a Noise handshake that proves both keys, then encrypts traffic with ChaCha20-Poly1305. An ML-KEM-768 key exchange is mixed into every handshake, so recorded traffic stays protected even from a future quantum computer.

A route adds a second layer. Its two ends run their own Noise session over it, so the visors in between forward packets they cannot read. Each of them knows only the visor before it and the visor after it.

Transports and dmsg

A visor fills itself with transports on its own. It dials public visors and visors connected to them, so it soon has enough links to build routes of several hops. Direct transports run over TCP, UDP with hole punching, QUIC, and the WebSocket, WebTransport and WebRTC links a browser can open.

dmsg is Skywire's relay network. A visor connects out to dmsg servers, so it needs no open port. To reach another key, a server passes an encrypted stream between the two visors. It cannot read the stream, and neither visor learns the other's IP address. A dmsg link can always be made, which is how a new visor reaches the network's services and its first peers before it builds direct transports. See the transports guide.

Routes and multipath

A route is a chain of one or more transports from one visor to another. An app connection rides a route group, a forward route and a reverse route, which need not take the same path.

A visor usually finds routes on its own, from its own transports and the signed transport lists of its neighbours, and asks the route finder service when it cannot. A routing policy, a small Starlark or WebAssembly program, decides how many hops and paths each connection uses and which peers to prefer or avoid. Nineteen policies come built in, from one lean low-latency path to maximum unlinkability.

One connection can use several routes at once. An app such as the SOCKS5 proxy spreads its streams over several tunnels, and inside each tunnel packets are striped over legs that take different first hops. When a path is cut, its packets are sent again on another leg and the connection carries on. This is for fail-over and privacy, not for speed.

See multipath routes and routing policies.

Names on the mesh

A service published on a visor is reached at the visor's key. <key>.skynet goes over transports and routes, and <key>.dmsg reaches the same visor through dmsg. A name to the left of the key picks a site on that visor, so one visor can serve many sites. Programs reach these names through a resolving SOCKS5 proxy built into the visor, through SkyDNS with no proxy setting at all, or through the browser built into the browser visor. See mesh addresses and publishing a site.

Running visors

Everything a visor does can be driven from skywire cli, and the same commands drive a visor on another machine with --via dmsg://<key>. Every command can print JSON, a jq filter is built in, and skywire --tui browses every command and its help interactively. Any visor can be a hypervisor and manage others from a web dashboard. The visors it manages dial out to it, so they can sit behind NAT, and only the keys a visor lists can control it. skywire cli pty opens a shell, runs a command or mounts a filesystem on another visor, addressed by key. See the hypervisor guide, driving a remote visor and the command reference.

Rewards

Skycoin is not mined. It is distributed through Skywire: 816,000 SKY a year goes to the visors on the public network that meet the eligibility rules, paid every day. Half is shared evenly among eligible visors, with duplicate addresses removed and a scaling that favours a spread of locations. The other half is shared by the bytes each visor carried over its transports during the day.

To be eligible a visor needs enough uptime, a recent version, a hardware survey that passes the checks, and a reward address. The reward address is the account xpub of a Skycoin wallet, so each day's payout goes to a fresh address. Browser visors are not eligible. skywire cli reward rules prints the full rules, the reward address guide shows how to set one, and payouts are announced in @skywire_reward on Telegram. The deployment page has more on how rewards are calculated.

Hardware

A visor runs on any Linux, Windows or macOS computer, on ARM boards such as the Raspberry Pi, and on an Android phone. The Skyminer is the project's own hardware, a cluster of single-board computers each running a visor. A visor that others can reach from the internet is what the network routes through, and making one takes an open port or two. Running a public visor explains the settings.

The network

The public Skywire network has about a thousand visors, most of them online at any time, with tens of thousands of transports between them. status.skywire.dev shows the live figures.

A Skywire network runs on a small set of services, called a deployment: dmsg servers, registries of visors, addresses, transports and services, a route finder, and nodes that set up routes and transports. They help visors find each other and get started. None of them can read traffic, and apart from the dmsg relays none of them carry it. The data they publish, such as the addresses of peers and the transports to route on, travels as signed feeds that a visor can check and keep a copy of, so a lookup is usually answered locally.

The Skycoin project runs the public deployment. The services are open source, they are in the same program as the visor, and one command sets up a private Skywire network of your own. The deployment services explains what each service does, how a new visor uses them, and how to run your own.

Documentation and community

The documentation is at skycoin.github.io/skywire. It has guides for every part of Skywire, a command reference generated from the program itself, and a terminal running skywire in the page. A visor serves the same documentation offline with skywire doc serve.

Ask questions in @skywire on Telegram, follow development on the blog, and watch @SkywirePSA for announcements.

Watch an introduction