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.
A hosted account is its Ed25519 storage key, and that stays so: the key is
what owns and decrypts the data. A Theseus ID is added as a way to look at
the account (usage, sign-up, sign-out) from a browser that does not hold the
key, which is the account-level login DESIGN-theseus-id.md §11.3 asks for.
The owner links an ID with a normal session plus a Theseus ID sign-in for
project "pithos" (POST /hosted/v1/theseus-id). The ID then signs in to
POST /hosted/v1/console/session and gets a "console" token, which reaches
/hosted/v1/me, its own sign-out and the link status, and is refused
everything else: files, rules, moves and the forwarded owner API. Sessions
stored before scopes existed read as owner sessions. A move to a new ID in
Theseus carries the account along.
The verifier is TheseusID/lib's message.mjs and verify.mjs, copied verbatim
into hosted/theseus-id/ with libauth doing the curve maths, so the gateway
adds no dependency; a test fails if the copy drifts.
With app: { dir, hosts } set, the gateway serves web/ at / and /_app/ for
those hostnames only. Sharing an origin with the API means the page needs
no CORS and keeps its keys away from every other site; the CSP keeps it
from loading or calling anything else. Signed S3 requests are routed
first, so a drive called _app is unaffected.
Public files were addressed by a 32-character account id, and a public
folder answered with JSON, so a link was unusable to send to anyone.
Accounts that signed up with a BNS name can now be addressed by it
(/p/alice.x/<drive>/<folder>/), a public folder opened in a browser is a
page with its files, small pictures and a player (tools still get JSON),
and every link and redirect on it is relative so navigate.st/s3/ serves
the same pages. Pithos shows the navigate.st/s3 address when a folder is
made public.
Renaming refused on hosted drives because encrypted names and contents are
bound to their path. The encrypting client now renames itself: readable
files keep s3d's server-side copy, the rest are decrypted and encrypted again
for their new place. A drive with shared folders or links is not renamed,
since its rules belong to the old name.
Free space is forwarded to the server, whose s3d answers for its own
folder, instead of reporting nothing. space.js now builds on sia-account.js,
so BLAKE2b and the indexer request signing exist once.
A person with several sia.storage accounts (or phrases) could not tell
which one a Pithos s3d used: s3d records only the indexer URL. Pithos now
reads the app key s3d stores after login and asks the indexer, with a
request signed the way indexd's app API expects, for the account's key,
storage used and last use. Those match what sia.storage shows for the app,
and the page explains that the login and the phrase together decide the
account. Earlier accounts set aside on this computer show their key too.
A server-sent file list could name paths outside the s3d folder (or the key
file in it), and a failed move back deleted every listed path. Transfers now
accept only s3d data paths, check all of them before writing, never
overwrite, and clean up only what they wrote.
A lost reply could lose or fork the drives: move-up and move-down now ask the
server who holds them before touching the local copy, and once the server is
told to release, the local copy is never removed (the release is retried).
The gateway no longer lets one account route another's access key id, refuses
. and .. in shared-key paths, strips presign parameters before re-signing,
counts upload size on disk, stops s3d before it can be restarted mid-move, and
claims sign-up proofs before checking them. The key file is never replaced
when unreadable, a local edit removes the older encrypted copy, listing pages
no longer repeat, and data hashes stream instead of loading whole files.
Records what was built against the plan (names are encrypted from v1, rights
for other people are folder-scoped S3 keys), how to run pithos-hosted, and
that paid storage belongs to Hestia, a separate product.
The gateway is the only thing standing between a shared key and the rest of
an owner's drive, so its SigV4 check, grant decisions and the BNS/deposit
proofs get tests that need no s3d to run.
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.
