Sanctum Share ships: phone-share to a URL agents can GET

Sanctum Temp is the ephemeral host. Sanctum Share is the Android share-sheet that lands phone shares at a direct URL — the wire your agents and tools can alre

Sanctum Temp is the ephemeral host. Sanctum Share is the Android share-sheet that lands phone shares at a direct URL — the wire your agents and tools can already GET. Sideloaded, not Play Store. SHA-256 verified against the OSS repo, not just the website.

Most Android share-sheets hand a file to another app. Almost none of them hand a file to an agent that can GET a URL. Sanctum Share is the small bridge that closes the gap — phone share, app, direct URL, agent. The pattern is mundane. The mundane part is what we built.

What it is and what it isn't

Sanctum Share is an Android share-sheet app. Package name org.sanctumos.share. Source lives at github.com/sanctumos/tmp-sanctum under android/. The repo is the public OSS workspace for both the app and the host behind it.

What Sanctum Share is not:

Not on the Play Store. We sideload. The download page is tmp.sanctumos.org/app/ and the newbie install steps live on that page.
Not a file manager, not a gallery, not a backup product. It is one thing: a share target that hands a file to the Sanctum Temp host and returns a direct URL.
Not a general-purpose upload tool. Sanctum Share is wired to the Sanctum Temp ephemeral host at tmp.sanctumos.org — the same tmpfiles-compatible surface SanctumOS runs in the slate/orange brand.

The job is small. The job is the job.

The wire: phone share to direct URL

The flow is the boring one:

Phone file is selected from any app that exposes a share intent (Photos, Drive, Recorder, the gallery, screenshots).
The user picks Sanctum Share as the share target.
The app uploads the file to Sanctum Temp.
Sanctum Share returns a direct_url — a URL the agent can GET against.

The four-step shape is the product. There is no login flow and no upload-queue UI. After upload you get Copy direct URL / Copy view URL. Home is pick-files plus a short Recent shares list — not a gallery, not a manager. Settings holds the Temp base URL. The rest of the surface is not the surface.

This is the same design posture the rest of SanctumOS takes: the smallest wire that lets an agent get the file. The share-sheet side stays thin so the agent side stays wide.

Where the URL lands — agents we ship against

The URL Sanctum Share hands back is the format agents already expect. Three concrete cases:

Venice image_interpret reads the direct URL as the image-source input. Phone screenshots, sign photos, document scans — anything the user can share into the app — flow into image_interpret as a normal URL input. No native integration, no plugin. The agent already knows how to fetch a URL.
Broca / Telegram pipelines accept the same direct URL as a media reference. A chat agent that needs the file from the user's phone gets it through the URL, with no sideloaded-MIME-type negotiation at the boundary.
Anything that does an HTTP GET can read the file. The agent surface is whatever the agent's tool list says it is. Sanctum Share is not in the loop at that point. The URL is.

This is the boring bit of the product: we did not invent a new protocol. The product is a small Android share target whose output is a URL. The protocol the URL rides on is HTTP.

Sideloading, the SHA-256, and the byte-for-byte question

The download page is at tmp.sanctumos.org/app/. The published APK is at /downloads/sanctum-share-latest.apk on that site. Newbie install steps — allow install from unknown sources, point the package manager at the APK — are on the same page.

The hash list is checked into the OSS repo at public/downloads/SHA256SUMS. The reason the hash lives in the repo, not only on the website: you verify the published APK against the git-trusted hash, not against the website-trusted hash. If the website is compromised and serves a swapped APK, the git-pinned SHA-256 in the repo will not match what you downloaded. If the repo is compromised, the website is already past the audit threshold and you have a bigger problem than the SHA. We picked the model that fails closed at the website boundary, and we check the git hash in the repo because that is the layer the operator actually trusts.

One thing we are honest about, in the same register: a self-built APK may not match the published SHA-256 byte-for-byte. The build pulls BuildConfig timestamps, the debug keystore, and other environment artefacts that produce a binary a few bytes off. The published SHA-256 authenticates the published binary against the same SHA-256 in the repo. Self-builds authenticate a self-build, and a self-build should be hashed on the build host you ran it on. If you self-build and want to publish under your own brand, the published-build pipeline is android/tools/publish-apk-to-public.sh in the repo. The published SHA-256 is the one consumers verify against.

Forks, branding, and your own Temp base URL

Forks are part of the design. The Settings panel exposes a Temp base URL field so the app can point at any instance of Sanctum Temp the operator runs. If you want a white-labelled version with your own brand:

docs/BRANDING.md walks the brand swap — colors, app name, icon, the slate/orange → your-color shift.
docs/ANDROID.md is the longer-form technical walkthrough of the Android module.
android/tools/publish-apk-to-public.sh is the script that publishes a forked APK with the new brand, so the fork can ship the same way the upstream build ships.

Forks are not a feature we built reluctantly. They are how the OS handles regions, internal teams, and operators who want a private Temp with their own retention rules. The brand color is the smallest part of the fork. The settings panel is the larger part.

v0.1.0 — what's in and what's pending

v0.1.0 is the first published build. It is labelled as a debug build on the download page, on purpose: we are not pretending the surface is finished.

What v0.1.0 ships:

the share-sheet flow end to end, returning a direct_url;
the configurable Temp base URL in Settings;
the slate/orange brand, the SanctumOS pack-label;
a working install path with sideloading instructions on the download page;
a SHA-256 in the repo that authenticates the published binary against the git-trusted hash.

What v0.1.0 does not ship:

upload-queue retry and offline-resume. If the network is flaky, the upload fails and the user retries;
automatic clipboard-cleanup timers. The URL stays in the clipboard until the user clears it;
a full in-app browser of every file ever uploaded to Temp — Recent shares is local history on the phone, not a remote file manager;
Play Store publication. Sideloading is the model until we have something we are willing to ship under Google's review;
anything beyond the v0.1.0 surface described in docs/ANDROID.md. The doc describes the module as it is; it does not describe the module as we are planning it.

If a feature is in the pending list, it is pending because we have not built it, not because we are keeping it a secret.

The download page is at tmp.sanctumos.org/app/. The repo is at github.com/sanctumos/tmp-sanctum. The hash list is in public/downloads/SHA256SUMS. The branding and Android docs are in docs/BRANDING.md and docs/ANDROID.md. The publish script is android/tools/publish-apk-to-public.sh. None of those links move between releases; the URL the app returns is the only URL that does.