User guideWayseer 0.28.3Contents

Newer releases

Wayseer downloads a release of itself only when you ask, or when you set updates.download, and installs one only when you press Y. Copies a package manager installed are left to it. When a newer release is out, it says so once, quietly, and says whether your license key covers it. You decide when, and whether, to install it.

The version in the strip

The right end of the status strip always shows the release you run, and whether it's current:

Wayseer fetches the signed file a few minutes after it starts, so a copy just started may show gray at first. Click the version to open the updates panel. A build you made yourself says Wayseer development build. A build with a build day but no version stamped in shows the day instead, such as Wayseer, built 2026-10-04. Releases before 0.28.0 have no version in the strip.

The notice

The background fetch that checks for newer revocation lists brings the same signed file to everyone. That file also names the newest release for each platform. When the release for yours was built after the one you run, the status strip shows one line:

Wayseer 1.6.0 is out; your key covers it

The line has one of these endings:

The line shows once for each release. Any key or click hides it, and it doesn't come back: not on the next fetch, and not after a restart. The next release has its own line. Wayseer keeps the releases it told you of in updates.yaml in its state directory. That file holds version numbers and nothing else.

A build you made yourself from source has no build date stamped in, so it never shows the line.

Installed by a package manager

When a package manager installed Wayseer, the line says to update with it:

Wayseer 1.6.0 is out; update it with Flatpak; your key covers it

The Flatpak, the Nix package and the Windows installer each say so. Wayseer reads a one-line installed-by file that the package puts beside the program or in share/wayseer/. If you package Wayseer for another system, write one there, such as Homebrew or the Arch package. Without the file, the line doesn't say where to get the release. Downloads are at wayseer.app.

What is newer

>updates.show opens the updates panel:

Beneath them, a newer module has rows of its own. Esc closes it. The same line goes to control and the language model, without your license ID or who the key is for:

no newer Wayseer is known; newer modules: acme/gauge 1.5.0

Downloading a release

>updates.install downloads the newer release for your platform and checks it. Only these copies download a release of themselves:

1. It downloads the release's signed file, wayseer-1.6.0.release, from https://wayseer.app/v1/app/1.6.0/, or the same path beside the url of a mirror (the fetch). On a Mac it is wayseer-1.6.0-darwin.release, which signs the macOS zip.
2. It checks that file first. Wayseer's release key must have signed it, under a root built into this release, and the revocation list held must not withdraw that key. It must be for the version and build day the signed list names, and list the package the list offers.
3. It downloads the package of the kind you run, such as wayseer-1.6.0-linux-x86_64.tar.gz, from the same place. Its size and SHA-256 must be the ones both signed files give. The macOS zip, wayseer-1.6.0-macos.zip, must have the size and SHA-256 its own signed file gives, since the signed list names only its version and build day.

Both files wait in downloads/ in the cache directory, the status strip says Wayseer 1.6.0 is downloaded and its signature checks out, and the updates panel offers it (installing a release). Running >updates.install again takes the download without another request.

The request is a plain GET with no license ID, no key and nothing else about you. It is HTTPS only, follows a redirect only to https on the same host, stops at the size the signed files give, and gives up after 30 minutes.

When something is wrong, the status strip says so in one line, nothing is kept, and the release you have keeps running:

A failed download ends Wayseer 1.6.0 isn't downloaded: and then one of these:

Installing a release

Once a release is downloaded and checked, the updates panel offers it:

Install Wayseer 1.6.0
Release    Wayseer 1.6.0, built 2027-03-01
           your key covers it
Signed by  Wayseer's release key; the package is the one the index offers
Replaces   /home/you/wayseer-1.5.0-linux-x86_64
           and keeps it as /home/you/wayseer-1.5.0-linux-x86_64.previous
                                     Y install · Esc keep this release

When your key doesn't cover the release, the second row says your key doesn't cover it: your paid modules lock until you add a renewed key (which releases a key covers). Y still installs it. With no key, the row isn't shown.

Y checks the download again, then installs it:

The status strip then says Wayseer 1.6.0 is installed; restart to run it. Wayseer never restarts itself, so the release you run keeps running, with its working set, until you quit. The next start runs the new release. Config, state and the cache are left where they are.

One previous release is kept, the one this install replaced; an older one is removed. Esc installs nothing: kept the release you run; nothing was installed. The download stays in downloads/, and >updates.install offers it again.

Before writing anything, Y reads the whole package and refuses it if any entry would land outside its folder, is a link, a device or another special file, or is hidden; if a file is over 512 MiB or the whole over 1 GiB unpacked, or it has over 4096 entries; or if it doesn't hold the program. If anything fails, the copy you run is left as it was, and the status strip says so in one line:

For example: Wayseer 1.6.0 isn't installed: the release isn't the one the index offers; the release you run is unchanged.

On Windows, a journal, .update, lists each move while the moves are made. If the install stops halfway, such as on a power cut, the next start moves everything back.

On a Mac

On a Mac, Wayseer doesn't replace the app itself. It downloads and checks the release as on the other systems, then leaves the last step to you. The updates panel offers it:

Install Wayseer 1.6.0
Release    Wayseer 1.6.0, built 2027-03-01
           your key covers it
Signed by  Wayseer's release key; the package is the one the index offers
Shows      Wayseer.app in Finder, unpacked in Wayseer's cache
           quit Wayseer, then drag it over /Applications/Wayseer.app
                                 Y show in Finder · Esc keep this release

Y checks the download again and unpacks it as downloads/macos/Wayseer.app in the cache directory, under the same rules as installing a release. Then it opens a Finder window with the new Wayseer.app selected, and removes the zip. The status strip says Wayseer 1.6.0 is in Finder: quit Wayseer, then drag it over /Applications/Wayseer.app.

1. Quit Wayseer.
2. Drag the new Wayseer.app onto Applications, or wherever your copy is, and choose Replace.
3. Open it as before.

Wayseer writes nothing outside its cache, so the app you run is unchanged until you replace it. If the unpacking fails, the status strip says why, as an install does: for example, Wayseer 1.6.0 isn't unpacked: the release isn't the one the index offers; the release you run is unchanged. Wayseer keeps no earlier release on a Mac, and >updates.undo has nothing to bring back. To go back, download the earlier zip from wayseer.app.

Undoing an update

>updates.undo puts back the release the last update replaced and removes the one it installed. The release you run keeps running, so the status strip says the release the last update replaced is back; restart to run it. Undone in the same run as the install, it says Wayseer 1.6.0 is undone; the release you run is back in place, and >updates.install offers 1.6.0 again.

If the new release doesn't start, wayseer --undo-update does the same from a terminal, without a window, a config or a license key:

$ ~/wayseer-1.5.0-linux-x86_64/bin/wayseer --undo-update
the release the last update replaced is back in /home/you/wayseer-1.5.0-linux-x86_64

On Windows, run wayseer.exe --undo-update from the folder. Windows doesn't let a running program be deleted, so the release undone waits in the folder's .undone\ until Wayseer next starts.

Only one earlier release is kept, so one undo is all there is; it can't go back two releases. When there is nothing to bring back, it says so in one line and changes nothing:

An undo that fails halfway puts the release you run back as it was. On Windows it keeps its own journal, .undo, which the next start moves back the same way.

Newer modules

The same signed file names the newest version of each marketplace module and what its manifest declares. When it offers a version of an installed marketplace module with a higher version number than the newest one you have, the updates panel lists what that version would change:

Module  acme/gauge 1.5.0, 1.4.0 installed
        adds actions drain
        drops actions power
        adds endpoints telemetry.acme.example:443
        now reads the keyring

• Adds and drops rows compare the actions, kinds and endpoints the newer version declares with those of the manifest you installed (what a module declares). With no difference, the row says declares no other actions, kinds or endpoints.
• The keyring row says now reads the keyring, no longer reads the keyring, or, unchanged, whether it reads it.
• needs a newer Wayseer takes the place of the rows when the newer version speaks a module contract this Wayseer doesn't.

The panel lists five modules and counts the rest; each is cut to nine rows, as the sources panel cuts a manifest. A package signed under a developer certificate is never listed, since the marketplace doesn't publish it. Listing a module downloads nothing; take it with >modules.update. Module notices work in a development build too.

Updating a module

>modules.update id=acme/gauge takes the newer version of an installed marketplace module:

1. It downloads the version's package for your platform from beside the signed file, at https://wayseer.app/v1/modules/acme/gauge/1.5.0/, or the same path beside the url of a mirror (the fetch).
2. It checks the package before anything else: its size and SHA-256 must be the ones the signed file gives, the marketplace must have signed it, and its manifest must declare what the signed file says it does.
3. It opens the updates panel on what the version changes, the same rows as newer modules, and waits:

Update acme/gauge
Module     acme/gauge 1.5.0, 1.4.0 installed
           adds actions drain
           doesn't read the keyring
Signed by  the marketplace; the package is the one the index offers
                                          Y install · Esc keep 1.4.0

Y installs it, as installing a package would, checking it again under your key and the revocation list held. Each source that names the module with no version then restarts on the new version, and the status strip says installed acme/gauge 1.5.0; restarted ext on it. A source whose config names a version keeps running that version. Esc installs nothing: kept acme/gauge 1.4.0; nothing was installed.

The download needs a license key, as installing does. The request is a plain GET with no license ID, no key and nothing else about you, the same as the fetch of the signed file. It is HTTPS only, follows a redirect only to https on the same host, stops at the size the signed file gives, and gives up after five minutes.

When something is wrong, the status strip says so in one line, and the version you have keeps running:

For example: acme/gauge isn't updated: the package isn't the one the index offers.

Downloading in the background

updates:
  download: true

With updates.download: true, each fetch that finds a newer version of an installed marketplace module also downloads its package and checks it as >modules.update does. It never installs it. >modules.update then shows the offer at once, without a request. A fetch that finds a newer Wayseer downloads and checks its release in the same way, as >updates.install would, for the copies that download their release; a copy a package manager installed makes no request. >updates.install then offers it without a request. Nothing installs without Y. Downloads wait in downloads/ in the cache directory. One that no longer checks out is fetched again, and an installed module's download is removed. A download that fails is logged, and shows nothing. download is off unless you set it, and does nothing while updates.check is off.

Turning it off

updates:
  check: false

With updates.check: false, Wayseer shows no notice, lists no newer module and downloads nothing in the background, and the panel says checks are off. >modules.update and >updates.install still work from the signed file held. It shows nothing even when the revocation check fetched the file. The revocation check is separate: turning off update notices never turns it off. With both checks off, Wayseer makes no request at all (air-gapped hosts).