The share menu now shows the real Telegram, WhatsApp and X marks. In
Theseus, Telegram and WhatsApp open in its sidebar apps, where the user
is already signed in, at their share screens (Telegram Web's tgaddr
share, WhatsApp Web's /send); elsewhere the apps' own share links hand
over to the installed app as before.
The sidebar's Full page button is gone: the panel's own Maximize does
the same, and the narrow-layout menu keeps "Open in a tab".
A first Pithos app for phones. It runs the browser app in a WebView and
answers the page's own files from the APK under the gateway's origin, so
the page stays the same-origin client it was designed as and the files
are still encrypted and decrypted in the page.
What the phone adds: "Save to Pithos" in other apps' share menus (the
files wait in a bar until a folder is open), downloads written to the
Downloads folder, the system file picker for uploads, and outside links
opened in the phone's browser.
The browser app learns the two hooks (window.PithosAndroid) and says
plainly when a browser is too old to sign in, instead of a bare
"NotSupportedError".
Share used to copy the link straight away, leaving no way to send it
anywhere. It now opens a menu with the link and Copy, Open, X, Telegram
and WhatsApp, plus the link options. The ⋯ menu's "Copy public link"
still copies in one step.
A person opening a single-file link in a browser used to get the bare
file, with nothing saying where it came from. Browser visits now get a
page with a preview, Download and Open, and links to pithos.sia, the
Pithos app and Theseus Navigator; folder pages carry the same links.
Players, embeds and download tools still get the file itself (?raw,
?dl, or any request that is not a page navigation).
On a 1920px screen Pithos used about 60% of the window: the content
stopped at 1100px and the text stayed small, so it took 150% zoom to
fill the screen. Sizes are now in rem and the root size grows past
1440px wide (about 1.25x at 1920), and the content takes the full width.
The narrow sidebar panel is unchanged.
Open in browser floated in the middle of the sidebar because it and
Back to sidebar each pushed themselves to the bottom. The host's buttons
now share one row above the s3d status.
A renamed user kept its old name in the full page and in the other open
views until they were reloaded, and the pithos.sia address still named
the old user. The server now tells every view, and each one updates its
selection, its address and the page on screen.
When the vault locked while pithos.sia was open, the page fell through
to the console password sign-in, which a Theseus user has no use for.
It now shows the vault's PIN unlock, and it opens again on its own
once the vault is unlocked anywhere, the sidebar's PIN pad included.
The sidebar likewise opens again when the vault is unlocked elsewhere.
test/theseus-id.test.js imports hosted/server.js, which needs
@bitauth/libauth from hosted/node_modules; the runner only installed the
app's own dependencies, so the job failed before building.
Share opened a dialog with a duration and a Create button before anything
happened. Now Share copies the link already made for that file, folder
or drive, or makes one and copies it, then shows Open and Manage; the
full list (and Switch off) is behind Manage. A Sia share link is signed
with an end date, so new links get the longest Pithos allows, 10 years.
When a file cannot reach Sia yet, the message says why instead of
passing s3d's admin error through.
Creating a public link in the Theseus add-on failed with 'Unknown cipher':
Electron's BoringSSL has neither chacha20 nor chacha20-poly1305 in
createCipheriv, and the tests only ran under Node's OpenSSL. Opening Sia's
32-byte data key now uses RFC 8439 ChaCha20 and Poly1305 written out in
JS; the Go x/crypto vectors pass under Node and inside Electron 44.
s3d has no rename command, so a user named once kept that name. A user is
one row in s3d's database (id, name) and keys and drives point at the id,
so Pithos stops s3d (gently, after any upload), changes the name in
place, updates its own public-link records and starts s3d again: access
keys, secrets and drives stay as they are and S3 apps keep working.
Checked against s3d v0.2.0: the old key still lists the same drives,
taken and invalid names are refused.
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.
When s3d still lists a file as waiting but its buffered copy is gone,
Upload now fails with a raw admin error and nothing says which files are
behind it. Overview and Drives now list them (waiting, copy missing in
two checks a moment apart, no upload running, older than two minutes),
each with Upload again… (replace it from the original) or Remove, and
Upload now explains the cause instead of passing s3d's error through.
On Windows s3d was stopped with TerminateProcess. One killed during an
upload (a Theseus restart, a cut-off flush) had deleted four buffered
files without recording them as uploaded; every flush afterwards failed
on them and the files were gone.
A stop now waits while a flush Pithos started is running, or while s3d
has begun an upload batch in the last two minutes (up to five minutes;
twenty seconds when the host is quitting), then asks s3d to shut down
cleanly: Ctrl+Break sent to its own hidden console on Windows (Windows
disables Ctrl+C in a new process group; Go reads both as an interrupt),
SIGTERM elsewhere. It is ended by force only if still there a minute
later. Checked against s3d v0.2.0: 'shutdown complete', exit code 0.
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.
Whether a drive was readable by anyone was only visible in the Drives
list or behind the Access button. The drive's path now carries a chip
(Private / Public / Public + list) that changes it in one click, and a
Share button for the folder you are in, or the whole drive at its top
level: a navigate.st/sia page on this computer's s3d, the Share… rules
on Drives on Silent Mode. The public-link route accepts the drive's top
level for that.
On a CI runner electron-builder assumes a GitHub release and writes
auto-update files for it; with no repository it then crashed after the
Linux packages were built. Pithos ships through its own channels
(dl.silentmode.st and the release manifest), so publishing is off.
A page served by the gateway that signs in with the Pithos key file
(Ed25519 in Web Crypto) or an Export JSON S3 key, then browses, views,
downloads, uploads, renames and deletes, encrypting and decrypting in the
page with the same formats as the desktop. Checked against a local
gateway and real s3d: files the desktop encrypted open byte-identical in
the browser, and browser uploads open in the desktop client; the server
only ever holds encrypted names. Remember on this device keeps the key
sealed with a passphrase in IndexedDB.
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.
The browser app must read and write the same encrypted files as the
desktop Pithos. web/lib/crypt.js reimplements core/crypt.js on Web
Crypto (AES-SIV and CMAC built from AES-CBC with a zero IV and AES-CTR,
since Web Crypto has neither), and web/lib/sigv4.js the SigV4 signing.
Cross-tests: the RFC 5297 vector, identical drive keys and names, bodies
encrypted on one side and opened on the other (empty, chunk-edge and
multi-chunk files, ranges), tamper and wrong-path rejection, and equal
SigV4 headers and presigned URLs.
Records why it must live on its own origin (every navigate.st/bns site
shares one origin and could read its keys), the two sign-in keys, the
AES-SIV port WebCrypto lacks, and the phases.
pithos.sia itself is the website, so people had no obvious address to
type for the app. /app (and /app/<page>) now opens Pithos in Theseus and
through the website's Open my Pithos; it is no longer read as an S3 user
named app.
Builds the AppImage, .deb and tar.gz on tag or by hand, runs the tests and
a headless first-run check (per-user paths, the pinned s3d, the pty), and
keeps the files with their checksums for 14 days.
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.
macOS packages can only be made on macOS. The workflow builds dmg and zip
for Apple Silicon and Intel, ad-hoc signed (Apple Silicon will not start
an unsigned app; there is no Developer ID yet, so Gatekeeper asks once),
then smoke-tests the packaged server, the macOS s3d install and the pty
before uploading the files with their checksums.
Export JSON… gives scripts and agents one file with endpoint, key, secret
and drive. The desktop app now ships for Linux too (AppImage, .deb,
tar.gz), using per-user s3d paths there.
With Linux builds joining Windows in the release list, the check must only
compare builds for its own system, and the link must fetch the Linux
AppImage (or, later, the macOS dmg) rather than the Windows installer.
s3d's Linux defaults (/etc/s3d/s3d.yml, /var/lib/s3d) are for a system
service; a desktop user cannot write them, so the desktop app could
never create its config. When no system config exists and those places
are not writable, Pithos uses ~/.config/s3d/s3d.yml and
~/.local/share/s3d (XDG), and writes the directory into the new config
so s3d itself, started with S3D_CONFIG_FILE, uses the same place.
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.
Sia Storage never tells an app who signed in, so accounts showed up as
"Sia account" until someone found the label field. The approval step,
where people are signing in to Sia Storage anyway, now asks for that
email and saves it as the label; the sidebar card names the account the
moment approval lands.
The desktop app had no way to learn about updates. Its footer now checks
Silent Mode's release list (through the local server, so the console's
CSP stays same-origin) and offers the matching installer or portable
build.
Until now the desktop app only ran from a source checkout, so Pithos was
really usable only inside Theseus. electron-builder (the version Theseus
uses) now makes an NSIS installer and a portable exe; s3d is still fetched
on first run by the checksum-checked installer, so the app stays small and
never ships an s3d it did not verify. Icons are rendered from ui/icon.svg.
Quitting also no longer waits on idle keep-alive sockets before exiting.
Files in your own Sia account can now be shared with anyone through a
navigate.st/sia link that keeps working with this computer off; the
navigate.st service is live, so the buttons can ship.
A share link from s3d only opened where s3d is reachable, which on a
default setup is this computer. Pithos now makes a Sia shared-object URL
for the file the way the Sia SDK does (the indexer's sealed object, its
data key opened with a key derived from s3d's app key) and registers it
at navigate.st, which streams the file from Sia hosts for anyone, with
seeking, even with this computer off. A shared-object URL reads that one
object and nothing else in the account. Files still waiting on this
computer are uploaded first. A folder gets a page with its files and a
player. Settings lists the links, each one can be switched off.
sia-share is the navigate.st side, in Go on the Sia SDK: it keeps short
ids, checks every URL against an allowed indexer, serves files sandboxed
so a shared page cannot run script on navigate.st, and caps sign-ups per
address and downloads per link per day. Host reads are paid by its own
app on Silent Mode's indexer account.
The name and icon at the top looked like a link to the main page but did
nothing. They now open Overview, in the sidebar, the full page and the
web console.
With drives on Silent Mode open at s3.silentmode.st, making a folder
public now shows its navigate.st/s3/<name>/<drive>/<folder>/ address:
a page anyone can open, by the account's BNS name instead of its id.
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.
The Accounts page opens with every Sia account on this computer side by
side, with Switch to and Add another account; Cancel closes dialogs
again and Escape works after a ⋯ menu; the footer's update applies the
new version in place on a Theseus that supports it.
Switching to another account, or adding one, was at the bottom of the
page, under the label editor and a long explanation of which account is
which. The page now opens with the accounts on this computer side by
side: the one in use (with its free space), each set-aside account with
Switch to, and Add another account. The account's details follow.
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.
Cancel did nothing in the confirm dialogs (delete, switch account) and
in Add another account: the dialog helper read a Cancel result of false
as "keep the dialog open", a meaning meant only for actions like Copy
link. A fixed result now always closes; only an action that returns
false keeps the dialog. Picking an item from a ⋯ menu also left that
menu's Escape listener behind, so Escape no longer closed any dialog
opened from it.
