Self-Hosting the Identity Site

The identity site is a static SvelteKit build under Apache-2.0, and nothing in it is bound to swarm-id.snaha.net. An app can serve its own copy. The reason to do it is the browser’s notion of site: an app on app.example.com embedding an identity site on id.example.com is same-site, so the proxy iframe reads the identity origin’s first-party storage directly. No storage partitioning, no popup handover, no third browser context on first run. This is how the canonical deployment already runs: swarm-demo.snaha.net embeds swarm-id.snaha.net, both under snaha.net.

What it takes

1. Build ui/ with BASE_PATH set to the path you serve it from (the hosted deployments use /id), and PUBLIC_BUS_SIGNALING_URL pointing at a signaling server you run, or leave it unset to run without cross-device sync.
2. Serve the build from a subdomain of your app’s site, over HTTPS, with the same registrable domain. Ports do not affect site; the scheme and the registrable domain do.
3. Point your SwarmIdClient at it with iframeOrigin.
4. If you use a subsidised gateway or your own Bee node, allow the identity origin in its CORS configuration, not the app’s: the iframe is what uploads. See Using Your Own Bee Node.

What it keeps

The property that makes the design honest survives intact. A different origin keeps its own storage, so the app’s JavaScript still cannot read the seed. Passkeys are unaffected either way: the ceremony runs in the identity origin’s own popup, so they work from the app on any deployment. What same-site adds is storage, not credentials.

What it costs

• Every user signs up again on your origin. The account itself carries over: every key the account makes derives from the recovery phrase, and the drives travel in the synced record, so the same phrase is the same Swarm ID on your origin and on swarm-id.snaha.net. The unlock does not: passkeys bind to the RP ID and the vault lives in the origin’s own storage. A user with an existing Swarm ID enters the phrase on your site, chooses an access method there, and the account restores from Swarm like on any new device.
• Backup and recovery are yours. Every support question about a lost account lands with you.
• You track a security-critical fork. Seed vaults and key derivation move fast in this repository. Bugs there lose data irrecoverably, and a copy that falls behind does not get the fixes.

Weigh the onboarding win against that rather than assuming it wins. For an app whose users already have a Swarm ID, or who will use several apps, the hosted identity spares them a second sign-up and a second vault to look after; the partitioned path works on every current browser, and the connect popup is one window.

What it does not change

Nothing about the data. Identity and storage are separate layers: ciphertext goes from the browser to the Swarm network through a Bee API, addressed by content hash and kept alive by the user’s postage batch. Gateways are entry points, not storage. Self-hosting the identity site moves where the seed lives; the blobs are already where they should be.