In Theseus, Pithos now links the person's Theseus ID to their hosted account
by itself, once, right after signing in to Silent Mode (or on the first look
at an account already signed in): one consent prompt, then Pithos is listed
under Settings › Theseus ID. On a Theseus without the add-on API it does
nothing, so the add-on can ship before the Theseus release that carries it.
The gateway serves /console on its own origin: sign in with the Theseus ID
and see the account's state, sign-up, usage and Theseus ID, with a console
session that cannot reach files. Three fixed files under a CSP that allows
only this origin.
The bundled copy in TheseusNavigator/bundled-addons/pithos is rebuilt from
Pithos/ with no version bump; the release that ships it bumps the version.
The Share dialog showed a bare code box and repeated its own title. It
now lists the links already made for that file, folder or drive as cards
(address, expiry, file count, Copy, Open, Switch off) above one line to
make another, copies a new link straight away, and also shows the
pithos.sia/l/<id>/<name> form, which Theseus and the pithos.sia site send
on to navigate.st/sia.
After an in-place update Theseus swaps an add-on's files but Node keeps
the modules already loaded, so the engine kept running the old version
while the footer showed the new one (a whole-drive link then failed with
'a file is required'). The engine now reports the version it loaded and
the one installed; when they differ the footer offers Restart to finish.
Pithos runs on the user's computer, so the pithos.sia website could only
describe it. Two ways in now:
- Open in browser (Theseus, desktop) opens the current page in the default
browser with a one-time sign-in link (60 s, single use), unlike the
host's reusable ?t= link.
- The website links to http://127.0.0.1:47621/open?path=/<user>/<drive>.
Any page or local program could follow that link, so the host first
asks the user in its own window (a native dialog on the desktop,
Theseus's approval prompt with the vault unlocked). Only loopback Host
names are accepted, one question at a time, and the website learns
nothing either way.
Sessions started this way are marked external, so the browser does not
get host-only controls such as Back to sidebar.
People setting up backups or AI agents want one small file with the
endpoint, key, secret and drive, in the shape scripts read. Export JSON…
in the key dialog writes exactly that, with a drive picker since a key
reaches all of its user's drives. The secret stays masked in the preview,
and the dialog says the file is unencrypted and suggests one S3 user per
agent. The Theseus save dialog now offers .json for it instead of
.pithoskey.
On a Theseus that can apply an extension in place, the footer's update
downloads the new version and reloads Pithos on it straight away. Older
Theseus versions still offer Restart to apply.
An .html file in a drive could only be read as source. It can now also be
opened as a web page in a new tab (Theseus tab, browser tab, or the system
browser from the desktop app), with the CSS, images, scripts and pages
beside it loading as they would from a website.
The page is served under a sandbox CSP without allow-same-origin, so its
scripts run in an opaque origin: they cannot read the Pithos session or
reach its API, only the files of the folder the page link covers. Links
are random, last an hour from last use (12 hours at most), and refuse
paths that leave the folder. Pages decrypt on the fly for drives hosted
on Silent Mode.
The new site mode recognises a path by the s3d's user names. With drives on
Silent Mode the local s3d has none, so it now asks the server for them;
otherwise pithos.sia/<user> links stop working once drives move.
Full page opened Pithos at a loopback address such as
127.0.0.1:58678/#/buckets/music-house, which means nothing to anyone
reading it and changes every launch. In Theseus the app now lives at
pithos.sia/<S3 user>/<drive>/<folder>, with pages at pithos.sia/settings,
/account and so on; the root page stays the pithos.sia website.
The add-on answers those paths through Theseus's new site routes. It
passes the session to the control server only for pithos.sia's own
requests and the address bar, never another site's fetch, and only
while the vault is unlocked, as the sidebar panel requires. The server
answers its own files, pages and existing S3 users and reports
anything else as not its own, so the website answers it. The sidebar
and the web console keep #/ addresses; an older Theseus still gets the
loopback address.
Pithos moved to 0.3.9 on master while hosting was built here, so the version
stays master's until the next release is cut. The hosted pieces were carried
into master's new layout: Share for folders lives in the item menu, files the
server can read keep their mark in every view, and other accounts show their
key and cannot be switched back to when they moved to Silent Mode.
Pithos only updated when Theseus happened to check the extension
channel on a restart, and nothing showed which version was running.
A footer now shows pithos.sia and the version, as Aegis's does. In
Theseus it checks the channel when Pithos opens and every six hours;
a newer release shows as "↑ vX", one click downloads and verifies it,
and a second asks Theseus to restart and apply it. ↻ checks on demand.
s3d binds one Sia account per process, so the server runs one s3d per
person (pithos-hosted), started on demand and flushed and stopped when idle.
Only the connected s3d data folder moves between PC and server; the Sia
recovery phrase never leaves the PC and nothing is re-uploaded to Sia.
Because the server holds the connection key, local Pithos encrypts names and
contents before they leave the machine, with keys from the Theseus vault (or
a local key file elsewhere). What s3d cannot do on its own, the gateway now
enforces: public folders, expiring share links and S3 keys for other people
limited to one folder with read, add-only or edit rights. Files those reach
are stored readable, since visitors have no key, and go back to encrypted
when the rule is removed. Sign-up needs a BNS name signature, a deposit or
an invite, with a per-IP limit.
- s3d kept stopping: Pithos stopped it whenever the extension restarted
(every update, every Theseus quit) and never started it again. Start
and Stop now record what the user wants (pithos-prefs.json beside
s3d.yml); Pithos starts s3d with Theseus and when opened, and retries a
crash up to three times in ten minutes, logging why it skips. The
Buckets page also redraws when s3d starts or stops; it used to keep
saying "not running".
- One view at a time: "Full page" opens Pithos in a tab and closes the
left panel; the tab has "Back to sidebar", which reopens the panel.
- Every new user gets a bucket of their own, named after them (lowercase,
hyphens) or as typed in the New user dialog.
- Buckets show as folder tiles. New folders are kept while empty with the
usual "<name>/" marker object.
- A viewer: images, audio (mp3 and friends), video and text open inside
Pithos, with Share and Download. The Theseus panel uses 10-minute,
reusable, inline view links so players can make range requests.
- The Access dialog says what s3d cannot do: per-folder public access and
write rights for others are not supported, only whole-bucket public read.
Wherever a key pair is shown (the guide's last step, the key dialog) a
"Save credentials" button writes it to a .pithoskey file, and Users &
keys gains "Open saved credentials" to read one back.
- With a password (any host): PBKDF2-SHA256, 600k iterations, AES-256-GCM,
done in the page with WebCrypto.
- With the Theseus vault (default in Theseus): AES-256-GCM under a key the
add-on derives from the vault (pithos/credentials/v1, now fixed), so
there is no extra password; a locked vault raises the PIN prompt first.
The add-on saves through a native dialog, since the sidebar page has no
download path.
Only the user name and date stay readable, to tell files apart.
Registers its panel with side: "left", so Theseus shows it in the quick-links strip beside the web apps instead of the right sidebar. Theseus builds without left panels ignore the field and keep it on the right.
In Theseus, Pithos now opens only with the vault unlocked: it asks
Theseus for the unlock (api.vault.requestUnlock), and Theseus shows its
own PIN prompt, falling back to the master password after three wrong
tries. Pithos never sees either. When the vault locks (Settings > Lock
now) Pithos locks within a few seconds; the add-on watches from the main
process because a hidden panel's timers run about once a minute.
The guide's phrase step gains "Use my Theseus vault" (the default when a
vault exists): the add-on derives the 12-word phrase from the vault
(purpose path pithos/sia-recovery/v1, first 16 bytes as BIP-39 entropy)
and hands it straight to s3d, so there is nothing to write down and the
vault backup restores storage access. The path is now fixed; changing it
would cut users off from their data.
Needs the vault-derive capability. On a Theseus without requestUnlock it
runs ungated, as before.
In Theseus the console opened as a tab at http://127.0.0.1:<port>, a raw
local address in the URL bar. It is now a left-sidebar panel instead,
loading the add-on's own ui/index.html: API calls, uploads and live
events cross the add-on IPC bridge and the add-on forwards them to the
control server with an internal session. Downloads go to Theseus's
download manager through single-use 60-second links. The panel can widen
to full window or open as a tab.
The core gains internalSession() and downloadUrl() for that; web and
desktop hosts keep talking HTTP as before. Grids now shrink to fit, so
narrow hosts never scroll sideways.
s3d is driven entirely by a CLI and a two-route admin API, which keeps
Sia storage out of reach for anyone who does not live in a terminal.
Pithos wraps it: install the pinned s3d release (checksum verified),
start/stop and logs, indexer login, users and access keys, a bucket and
object browser with share links and public-read policies, and the
upload pipeline stats.
One control server (core/) serves one UI (ui/), and three hosts run it:
a web console, an Electron desktop window and a Theseus add-on, so a
feature lands everywhere at once. The server binds loopback, rejects
foreign Host headers, and signs views in with a one-time secret that
becomes a SameSite=Strict cookie. s3d login reads the recovery phrase
with term.ReadPassword, so it is driven through a pty, with a console
window fallback where the pty module is not shipped.
