Anyone who owns a BCDN name can now publish a Theseus extension, and every
Theseus can install it with the publisher's signature verified locally.
Gateway (Argus/src/gateway/public-gateway.mjs):
PUT /api/ext/<name>/<id>/<version> takes the gzipped tar, checks two BCH
message signatures against the name's current NFT owner (one authorises
the upload, one is stored in the channel), inspects the package
(addon.json at the root, id/version/main match, 8 MB cap), enforces
first-publisher ownership of an id and monotonic versions, and writes the
tarball, the extension's updates.json and community/catalog.json to Sia.
GET /api/ext/catalog reads the catalog back with CORS.
Theseus:
lib/publisher-sig.mjs recovers the signer of a channel entry; main.js
compares it with the publisher name's owner from Theseus's own chain
index before installing or updating, so neither the relay nor a tampered
catalog can pass off code under a trusted name. addon-updater.js gains
installCommunity() and accepts publisher-signed entries in the regular
update check (operator Ed25519 entries unchanged). Settings › Extensions
shows the community catalog with Install / Update; Settings › Plug-ins
links to theseus.x/plug-ins.
theseus.x:
/plug-ins/ is a separate page for the first-party plug-ins (Aegis,
Ariadne's Thread) with live versions and hashes; /extensions/ lists the
bundled extensions, the community catalog, and how to build and publish;
/extensions/publish/ signs and uploads a package in the browser with the
wallet that holds the publisher's name (session helper + wallet bundle
copied alongside).
Two follow-ups from user reports on the 0.5.x screenshot rollout:
- When the screenshot editor sidebar is maximized (fills the window) and
the user hits New Tab / Settings / any address-bar nav that opens a
different tab, the incoming tab was left invisible behind the sidebar.
setActive now auto-restores the sidebar to its pre-max width whenever
it detects a tab switch — the user can hit the maximize button again
on the way back. Pure additive change, no other setActive semantics
touched.
- The signed-add-on update pipeline failed the 0.5.0 tarball extract on
a Windows 10 install with the built-in bsdtar: `tar --force-local -x
-z -f …` — bsdtar doesn't recognise --force-local and errors out
before it opens the archive. Try the extraction WITHOUT the flag
first (safe with the posix-slash paths we already pass on every tar
we care about — bsdtar, GNU tar, MSYS2 tar) and fall back to WITH
--force-local only if the first invocation exits non-zero (MSYS2
path where a bare `C:/…` gets parsed as a `host:` prefix). Original
error message is surfaced on total failure so we can still tell what
went wrong.
The Settings > Extensions "Check for updates" button used to report
one of two lines: "N updates staged; restart to apply" or "All
extensions are up to date". The second collapsed several distinct
outcomes into one indistinguishable line, so a user seeing "up to
date" couldn't tell whether the check actually reached the endpoint
or the fetch had silently failed.
checkAndStageUpdates now returns { report, skipped? } with one entry
per installed add-on and a status of:
no-update-url — addon.json doesn't declare updateURL
fetch-failed — DNS / connection / HTTP error on updates.json or the tarball (detail carries the message)
up-to-date — endpoint reached, no version strictly newer than installed
signature-invalid — offered version's sig didn't verify against any baked-in pubkey
sha256-mismatch — downloaded tarball's hash didn't match the signed one
extract-failed — tar could not extract (detail carries the message)
manifest-mismatch — extracted addon.json didn't match signed id/version
staged / already-staged — success
The Settings UI now renders one row per add-on with that status, so
a "no update" outcome is never mistaken for a silent fetch failure.
Return shape is back-compat: if a caller expects a bare array, the
UI normalizes.
An end-to-end drive of the update flow against a local HTTP server hit
two Windows-only tar quirks that a first-cut MVP wouldn't catch:
1. Git-Bash tar (MSYS2), which comes first on PATH when Git-for-Windows
is installed, treats drive-letter paths as `host:file` remote-archive
syntax. Sidestepped with --force-local (also silently accepted by
Win10's built-in bsdtar and by GNU tar).
2. Even with --force-local, MSYS2's argv-conversion layer mangles
backslashes in Windows paths, so `C:\Users\...\tmp\dir` arrives at
tar as `C:\Users...\dir` and it can't open the path. Passing
forward-slash paths (`C:/Users/.../tmp/dir`) dodges the mangler;
bsdtar and GNU tar accept them as-is.
3. sign-addon-update.mjs was tar'ing the addon directory as a subfolder
(`screenshot/addon.json` inside the archive), so the client
extracted to `<tmp>/screenshot/` and then failed the id+version
re-check because addon.json wasn't at the root. Now the signer
tars the CONTENTS of the addon dir via `tar -C <addon-dir> .`, so
entries live at the archive root where the client expects them.
All three surfaced from `scratchpad/decoupling-test/run-test.mjs`, which
now walks the full path — sign, serve, fetch, verify, download,
extract, stage, promote, backup — plus three signature-tamper negatives
and the empty-pubkey short-circuit. 15/15 checks pass.
Decouples bundled-add-on updates from Theseus releases. An add-on
whose addon.json declares an updateURL can be republished at any time
without shipping a new Theseus installer; existing installs pick it up
on the next boot's +30 s background check.
Client flow (main-process only, no UI touchpoints in this commit):
initAddons()
├── promoteStagedUpdates() # promote signed stage if newer
├── seedBundledAddons() # bundle wins over on-disk if newer
└── AddonHost.discoverAndActivate()
30 s later:
└── checkAndStageUpdates() # fetch, verify, download, stage
Signature: Ed25519 over
"silentmode.addon-update-v1|<id>|<version>|<tarball-sha256>",
verified against a hardcoded set of operator pubkeys living in
addon-update-pubkeys.js. Domain-separated so the operator key can't
be tricked into signing a message with a different purpose. Empty
pubkey array is the shipping default — checkAndStageUpdates() then
short-circuits and no outbound requests are made, which is the safe
posture until the operator ceremonies a key in.
Payload: gzipped tar, extracted with the system tar (present on
Win10 1803+, macOS, Linux). Path traversal defended by tar's default
refusal of `..` entries; the extracted manifest's id + version are
re-checked against the signed values before staging.
Staged updates go to <userData>/addons-updates-staged/<id>-<version>/.
Promotion into <userData>/addons/<id>/ reuses seedBundledAddons's
backup dance: existing folder moves to
<userData>/addons-backups/<id>-<oldver>-<timestamp>/ so any local
edits survive.
New files:
- addon-updater.js — client
- addon-update-pubkeys.js — hardcoded pubkeys (empty; edit + rebuild to rotate)
- scripts/generate-update-keypair.mjs — one-time keygen
- scripts/sign-addon-update.mjs — operator packager+signer
- docs/ADDON-UPDATES.md — operator brief + threat model
Wired into main.js at boot; screenshot add-on's addon.json advertises
the reference updateURL for when the endpoint goes live.
