@@ -1,141 +1,85 @@ --- title: Private Sites -description: Owner-only and share-link sites that never touch the PDS, and how they migrate to permissioned data +description: Access-controlled static sites stored by wisp.place --- -Private sites are sites that only their owner, and anyone holding a share link, can open. -They are stored entirely by wisp and are **never written to your PDS**. +Private sites are static sites that are only available to their owner and people they are +shared with. Their files and metadata are stored by wisp.place, not in the owner's PDS, and +do not appear in the firehose. -## Why they are not on the PDS +Private sites are access-controlled, not end-to-end encrypted. The wisp.place operator can +read their contents. Use application-layer encryption if the host must not be able to read a +site. -The AT Protocol repository is a public broadcast medium: +## Uploading -- `com.atproto.sync.getBlob` is unauthenticated, so uploading site files as blobs makes - them publicly fetchable no matter what the app does -- `com.atproto.sync.getRepo` returns a public CAR of the repository -- `com.atproto.sync.subscribeRepos` broadcasts every commit, so writing a `place.wisp.fs` - record would publish the site's existence, name, and structure to every relay +In the web app, open **Upload**, select **Upload privately**, choose a folder, and set an +expiry. The site appears alongside public sites in the **Sites** tab. -Hiding a URL is not access control. So until AT Protocol ships permissioned data, private -sites live only in wisp's own storage, and `firehose-service` is not involved at all. +With the CLI: -## Creating a private site - ```bash -wisp private deploy --path ./my-site --name "draft" +wispctl private deploy --path ./report --name "report" ``` -Options: +The default expiry is seven days. Use `--expiry 0` for no expiry, or pass a number of +minutes up to one year: -| Flag | Meaning | -|---|---| -| `--path ` | Directory to upload (default `.`) | -| `--name ` | Display name. Not an identifier | -| `--expiry ` | Minutes until expiry. **Omit** for the default (7 days), **`0`** for never | - -Private sites are served from a dedicated host, `priv.wisp.place`, which never serves -public user content. - -## Expiry - -The same rule applies to sites and to share links: - -- **omitted** — the configured default is applied (`DEFAULT_PRIVATE_SITE_EXPIRY_MINUTES`, 7 days) -- **`0`** — never expires -- **`n`** — expires `n` minutes from now - -A share link is additionally clamped to its site's expiry, so a link can never outlive the -content it points at. - -An expired site stays visible **to its owner**, so it can be inspected or deleted. It is -closed to everyone else. - -## Share links - ```bash -wisp private share --label "for review" -wisp private shares -wisp private revoke +wispctl private deploy --path ./report --name "report" --expiry 1440 ``` -The share URL carries its credential in a query parameter: +Private sites are limited to 500 files and 100 MB in total. They cannot be updated in +place; upload a new private site and delete the old one when its contents change. -``` -https://priv.wisp.place//?k=wss_... -``` +## Opening a site -Treat that URL as a secret: +Each private site has its own `*.priv.wisp.place` address. Opening it requires one of: -- the token is generated from 32 random bytes and stored **only as a sha256 hash** -- it is displayed exactly once, at creation, and cannot be retrieved afterwards -- `wisp private shares` shows only a short non-secret prefix -- revocation is immediate and permanent +- the owner signed in with their AT Protocol account +- an account that has been given access +- an active unrestricted share link -Private responses are sent with `Cache-Control: no-store`, `Referrer-Policy: no-referrer` -(so the token cannot leak through an outbound link), and `X-Robots-Tag: noindex`. +Private sites cannot be mapped to a wisp subdomain or custom domain. Responses are not +cached by the browser or indexed by search engines. -## Access rules +## Sharing -| Requester | Result | -|---|---| -| The owner, signed in | allowed | -| A different signed-in account | denied | -| Anonymous, no link | denied | -| A valid share link | allowed | -| An expired or revoked link | denied | -| Any requester after the site expired | denied (except the owner) | +Expand a private site in the **Sites** tab to create and revoke share links. A link can be: -Every denial returns an identical `404`, so probing cannot distinguish an existing private -site from one that never existed, nor a revoked link from an expired one. +- unrestricted, so anyone holding it can open the site +- restricted to an AT Protocol account, so the recipient must sign in with that account -## Migration path to permissioned data (v2) +An account-restricted recipient can later open the private-site address while signed in, +without using the share link again. Revoking the share removes that access. -[Proposal 0016](https://github.com/bluesky-social/proposals/tree/main/0016-permissioned-data) -specifies **permissioned data** for AT Protocol: records with an access perimeter, held in a -permissioned repo per `(user, space)` and gated by a space credential. It is a merged -proposal with a work-in-progress implementation, not shipped protocol, so v1 does not depend -on it. +With the CLI: -v1 was shaped so the migration is additive rather than a rewrite: +```bash +# Anyone with the link can open it +wispctl private share --label "review" -**Identifiers.** A private site id is TID-shaped and record-key valid, because 0016 -specifies a space key (`skey`) as "analogous to a record key". The existing `siteId` can -become the `skey` unchanged. +# Only this account can open it +wispctl private share --to did:plc:... -**Ownership.** `owner_did` is immutable and is the subject of every access decision, which -matches 0016 keeping record authority on the user DID. +wispctl private shares +wispctl private revoke

+``` -**One decision point.** All authorization runs through `evaluateAccess` in -`@wispplace/private-sites`. It is a pure function over `(site, shares, principal, now)`. -Under 0016, a space may set `policy: managing-app`, in which case the space authority calls -the managing app's `com.atproto.simplespace.checkUserAccess` at credential-mint time to -decide whether to authorize a user. **wisp.place becomes that managing app**, and the body -of `evaluateAccess` becomes the body of `checkUserAccess`. +A new share link is shown once and cannot be retrieved later. Treat unrestricted links as +credentials. The share list retains its label, status, expiry, last-used time, and a short +non-secret token prefix. -**Principals, not transports.** `AccessPrincipal` is an abstract union — `owner`, -`shareToken`, `anonymous` — deliberately not "a cookie" or "a query parameter". Adding a -`spaceCredential` principal in v2 is a new variant, not a refactor. +Share links use the same expiry rules as sites. An omitted expiry uses the seven-day +default, `0` means no expiry, and a positive value is a number of minutes. A share can +never outlive its site. -**Grants as rows.** Share links are first-class records with stable ids, expiry, and -revocation, so they map onto either a simplespace member list or dynamic -`checkUserAccess` policy input. +## Expiry and deletion -**Content metadata.** Every file retains its path, size, MIME type, and sha256, so files can -be re-uploaded as permissioned blobs and reconciled by digest. +After a site expires, its links stop working and the site is removed. Deleting a private +site removes its files and all of its share links immediately. -### What migration will involve - -1. Create a space per private site, with wisp.place as the `managingApp`. -2. Re-upload each stored file as a permissioned blob, matching on the retained sha256. -3. Write file records into the owner's permissioned repo, keyed by the existing `siteId`. -4. Reimplement `evaluateAccess` behind `checkUserAccess`. -5. Serve reads through space credentials, keeping share links working as a wisp-level - grant that `checkUserAccess` honours. - -### What will not change - -Permissioned data provides **access control, not confidentiality** — the proposal is -explicit that it is not end-to-end encrypted and that servers can read the data they handle. -That is also true of v1. Private sites are private from other *users*, not from the wisp -operator. Anything needing protection from the operator requires application-layer -encryption, which is out of scope for both v1 and 0016. +```bash +wispctl private list +wispctl private delete +```