latent/PROPOSAL.md

# Proposal: `latent` — a phone-photo editor with a "develop it later" option

**Status:** proposed, not built. Self-contained — written so a fresh agent
with no prior conversation context can pick this up and implement it
without anything explained first. No repo exists yet; this file is the
seed of one.

## Motivation

A small, fun webapp: upload a photo from your phone, apply film-style
manipulation (grain, light leaks, vignette, halation, color-cast) in the
browser, and either download it immediately or — the silly, on-brand
part — send it off to "develop," which holds it server-side behind a
randomized delay (hours to days) before the link actually resolves to the
image. Getting your photos back later, like real film, on purpose, for
no practical reason except that it's a fun mechanic.

Named `latent` after the *latent image* — the real photographic term for
the picture that already exists on exposed film but is invisible until
developed. Both halves of this app map onto that word directly.

Two independent finishing paths off one editor, not two separate apps:

1. **Instant** — edit, then download directly, entirely client-side, no
   server touched. Optionally generate a share link for the edited image
   (explicit user action — "generate share link" — not automatic).
2. **Delayed** — edit, then "send to develop": uploads the result to
   server storage, assigns a `develop_at` time chosen randomly within a
   configured range, and gives back a link that won't resolve to the
   actual image until that time passes.

## Architecture

Static/client-heavy frontend (canvas-based editing, same "no build step,
plain HTML/CSS/JS" family as `typo`/`flit`/`wisp`'s frontend) plus a small
single-process server for the two paths that need persistence: share
links and delayed development. Reuses the shape already validated by
`wisp` — blob + SQLite metadata + a background TTL-style sweep — rather
than inventing a new storage pattern. No accounts, no auth: the link
itself is the credential, same as `wisp`.

Unlike `wisp`, this does **not** need end-to-end encryption — none of
this is sensitive, and the entire point is a link other people can open.
That actually makes the backend simpler than `wisp` despite doing more:
no client-side crypto, no key-in-fragment handling, just an opaque random
ID per stored image.

### Editing (client-side, no server involved until "generate link" or
"send to develop" is pressed)

All via `<canvas>` — pixel manipulation, no ML, no WASM needed for a first
pass:

- **Grain** — random noise overlay, opacity/size adjustable
- **Light leaks** — a handful of pre-baked semi-transparent PNG overlays
  (warm streaks/blooms near an edge), randomized placement/rotation per
  application so repeat use doesn't look identical
- **Vignette** — radial darken toward the edges
- **Halation** — bloom/glow around bright areas (blur a thresholded
  bright-pixel mask, screen-blend back over the original)
- **Color cast / white balance shift** — a few presets (warm/expired-film
  amber, cool/cross-processed teal, faded/low-contrast) rather than raw
  sliders for every channel — keep the UI to "pick a vibe," not a full
  Lightroom clone
- Adjustments should be non-destructive within a session (recompute from
  the original + a param object, not chained lossy operations) so
  dragging a slider back to zero actually gets you back to the original

### Server

Single process, SQLite for metadata (same pattern as `galr`/`stash`),
images as blobs on local disk (same pattern as `wisp`).

**Table `images`:**

| column | type | notes |
|---|---|---|
| `id` | text PK | random opaque ID, used in the URL |
| `blob_path` | text | where the file lives on disk |
| `mime` | text | |
| `created_at` | integer | |
| `develop_at` | integer, nullable | null = instant share (no delay gate); set = "send to develop" path |
| `expires_at` | integer | TTL sweep target — don't keep images forever regardless of path |

**Endpoints:**

- `POST /api/upload` — body: image bytes + `{ delayed: boolean }`. If
  `delayed`, server picks `develop_at` randomly within a configured range
  (e.g. env-configurable `DEVELOP_MIN_HOURS` / `DEVELOP_MAX_HOURS`) and
  returns the link immediately — the whole point is you get the link
  *before* it resolves, so you can send it to someone and both of you
  wait. If not delayed, `develop_at` is null and the link resolves right
  away (that's the "optional share link" path off instant download).
- `GET /i/:id` — serves the image if `develop_at` is null or already
  passed; otherwise a small "still developing, check back in ~Nh" page
  (server can compute and show a rough remaining time without revealing
  the exact `develop_at`, to keep a little mystery — exact behavior is an
  open question below).
- TTL sweep (interval-based, same "deliberately dumb, not push-based"
  precedent as `keep watch`/`wisp`'s sweep) deletes blobs + rows past
  `expires_at` regardless of whether they were ever viewed.

No auth on any endpoint — this is a public, no-accounts toy. Rate-limit
`/api/upload` (basic IP-based throttle) to avoid it becoming an open file
host.

## Open questions

- **Exact delay range** — "hours to days" is the pitch; needs an actual
  default (e.g. 2–48 hours?) and whether it's configurable per-upload or
  fixed server-side via env.
- **What the "still developing" page shows** — exact countdown vs. vague
  "come back later" vs. a tiny animated placeholder (fogged/blank photo
  silhouette) for flavor. Worth spending a *little* design effort here
  since it's the whole gimmick.
- **Filter presets vs. raw controls** — start with presets-only (faster
  to ship, more "fun toy" than "editing tool") and add fine controls
  later if it turns out sliders are actually wanted.
- **Mobile upload flow specifics** — `<input type="file" capture>` for
  direct camera access vs. just a normal file picker; probably both,
  file picker as the fallback.
- **Image size limits / re-encoding** — phone camera photos can be large;
  decide whether to downscale/re-encode on upload (bandwidth + storage)
  or store as-is up to some cap.
- **Retention for the instant/non-delayed path** — does a same-length TTL
  apply, or does it expire faster than the delayed path since it's a much
  more casual "just give me a link" flow?

## Non-goals

- No accounts, no galleries, no "your uploads" history — every image
  stands alone via its own link, consistent with `wisp`'s throwaway
  philosophy.
- No e2e encryption — deliberately out of scope, see Architecture.
- No collaborative/multi-user editing — one uploader, one result.