Four related UX/privacy/install changes.
1. **Logged-out lands on the public list.** The root route now shows the
same Home view as a logged-in user, minus their own private rows and
the "Ny aktivitet" button. The nav exposes a "Logg inn" button when
no session is present. Login becomes one click away, not the forced
landing — anyone can browse the public + semi list anonymously.
2. **Public activities link to /<owner_username>/list.** When a public
activity's owner has opted into a public list, the "Lagt til av X"
line renders X as a link to /<username>/list. Server populates
`owner_username` on every public-row serialisation (null when the
owner hasn't opted in, so the client just renders plain text).
3. **Conditional owner_id on semi rows.** The server now serialises
`owner_id` on a semi row ONLY when the viewer IS the owner. The
wire type's `ActivitySemi.owner_id` is therefore optional. This
solves the semi-delete UX without leaking attribution: owners see
Edit/Delete buttons on their own semi rows; non-owners get the same
bare row they got before. The privacy property is enforced at the
API boundary, not in client-side render logic.
4. **Mobile-friendly + installable PWA.**
- `manifest.webmanifest` with name, theme color, standalone display,
and a maskable SVG icon (icon.svg).
- Service worker (sw.js): cache-first for the bundled shell;
network-only for /api/* (we never cache session-dependent or
ciphertext data — see the comment in sw.js for the rationale).
Falls back to the SPA shell for navigation requests when offline.
- SW registered in main.ts only in production builds (import.meta.env.PROD).
- viewport-fit=cover + env(safe-area-inset-*) padding so content
doesn't slip under iOS notches when installed.
- WCAG 2.5.5 touch-target sizing: min-height: 44px on buttons,
with an explicit opt-out for tag-close buttons (24×24 still meets
the 2.5.8 minimum).
- 16px font on form inputs below 480px so iOS doesn't auto-zoom.
Server-side: server/index.ts now serves manifest, icon, and sw.js
from frontend/dist alongside /assets/*. The catch-all still serves
index.html so the SPA's /<username>/list path routing keeps working.
Smoke-tested with a production-mode server: manifest returns the
correct application/manifest+json MIME, SVG renders, sw.js is
loadable, and unknown paths fall through to index.html as expected.
26 tests still pass; both tsconfigs typecheck (frontend now pulls
vite/client types for import.meta.env.PROD); Vite build succeeds.
6.6 KiB
Vinterliste
A small end-to-end-encrypted app for collecting winter activities — things to do when winter feels long. Activities can be:
- private — encrypted client-side; the server only ever sees ciphertext;
- semi-public — visible to everyone, but the creator is not shown;
- public — visible to everyone, attributed to the creator.
See SECURITY.md for the cryptographic model. It's load-bearing
— read it before changing anything in shared/crypto.ts or the auth flow.
Stack
- Runtime: Bun 1.3+. TypeScript everywhere.
- HTTP: Hono on Bun.
- DB:
bun:sqlite(built-in), WAL mode. - Server password hashing:
Bun.password(argon2id) — auth verifier only. - Client crypto:
libsodium-wrappers-sumo(WASM — the SUMO build is needed because the standardlibsodium-wrappersdoesn't shipcrypto_pwhash). Argon2id viacrypto_pwhash; AEAD via XChaCha20-Poly1305-IETF. - Frontend: Svelte 5 + Vite. Private tag index in IndexedDB.
- Container: single
oven/bunimage, one volume for the SQLite file.
Layout
shared/ pure modules used by both server and frontend
crypto.ts libsodium-backed key derivation, AEAD, wrap/unwrap, helpers
types.ts wire-level types shared across the network boundary
server/ Bun + Hono backend
db.ts bun:sqlite, WAL, idempotent schema migration
session.ts opaque, server-stored sessions (httpOnly cookie)
auth.ts signup, challenge, login, logout, password change, recovery
activities.ts CRUD with visibility rules
tags.ts server-side (public/semi) tag store + autocomplete
index.ts Hono app + static frontend in production
frontend/ Vite + Svelte 5 SPA
src/lib/crypto.ts re-exports shared/crypto for bundling
src/lib/api.ts fetch wrapper for the JSON API
src/lib/auth.ts signup/login/recovery orchestration
src/lib/tagIndex.ts IndexedDB store for private tags
src/lib/session.svelte.ts in-memory DEK + current user
src/components/ Svelte 5 components (Login, Signup, Recovery, Home, …)
tests/ Bun tests
crypto.test.ts round-trip wrap/unwrap, AEAD, password change, recovery
Containerfile single-image build for podman
Running locally
You need Bun 1.3+ installed.
bun install
# 1. In one terminal — start the API on http://localhost:3000
bun run dev:server
# 2. In another terminal — start the Vite dev server on http://localhost:5173
# (it proxies /api to :3000)
bun run dev:frontend
The dev server writes the SQLite file to data/vinterliste.db. Set
VINTERLISTE_DB=/some/other/path to override.
Tests
bun test
The crypto tests cover:
- DEK wrap/unwrap via both the password and recovery paths;
- AEAD encrypt/decrypt round-trip, plus tamper and wrong-key rejection;
- password change preserves activity ciphertexts (DEK is the same);
- recovery unlocks even after multiple password changes;
- recovery-code normalisation handles dashes and casing;
- the safe alphabet excludes visually ambiguous characters.
Typecheck
bun run typecheck
Production build
bun run build:frontend # produces frontend/dist
NODE_ENV=production bun run start
The server serves the SPA from frontend/dist in production. All non-/api/*,
non-/assets/* requests fall through to index.html so client-side routing
still works.
Container (podman)
The provided Containerfile builds a single image that serves API + frontend
and persists the SQLite database in /app/data (one volume).
BUILDAH_FORMAT=docker podman build \
--build-arg BUILD_DATE="$(date -u +%Y-%m-%dT%H:%M:%SZ)" \
--build-arg GIT_REVISION="$(git describe --always --dirty 2>/dev/null || echo dev)" \
-t vinterliste:latest .
# Create a named volume for the SQLite file
podman volume create vinterliste-data
podman run --replace --name vinterliste \
-p 3000:3000 \
-v vinterliste-data:/app/data:Z \
vinterliste:latest
# Visit http://localhost:3000
The container exposes /api/health for healthchecks and bakes the build date /
git revision into both OCI labels and /etc/build-info.
Installable (PWA) + mobile
The SPA ships with a web app manifest (/manifest.webmanifest), an SVG icon
(/icon.svg), and a small service worker (/sw.js) that caches the bundled
shell for offline reads. The API itself is never cached — sessions and
ciphertexts must come fresh from the server. On supported browsers
(Chrome/Edge on Android and desktop, Firefox with the flag) you'll see an
"Install" prompt; on iOS you can Add to Home Screen but iOS doesn't render
SVG icons, so the home-screen icon will fall back to the page screenshot.
Layout adapts to small screens via:
viewportset towidth=device-width, initial-scale=1, viewport-fit=cover- safe-area insets in
paddingso content doesn't slip under iOS notches min-height: 44pxon buttons (WCAG 2.5.5 enhanced touch target)font-size: 16pxon inputs below 480px so iOS doesn't auto-zoom
Promoting a moderator
Moderators can delete any semi or public activity (not private — those
aren't visible to anyone else anyway). There's no admin UI; promotion is a
one-liner against the SQLite file:
sqlite3 data/vinterliste.db \
"UPDATE users SET is_moderator = 1 WHERE email = 'olemd@example.org';"
The user has to log out and back in for MeResponse.is_moderator to refresh.
Manual verification
After signing up an account, the spec asks you to inspect a private row
directly in the DB and confirm only ciphertext is stored:
sqlite3 data/vinterliste.db \
"SELECT id, visibility, title, loc_label, scheduled_at,
length(ciphertext) AS ct_len, length(nonce) AS nc_len
FROM activities WHERE visibility = 'private';"
You should see title, loc_label, and scheduled_at all NULL, and the
ciphertext / nonce columns populated.
Status / scope
This is the scaffold from winter-list-claude-code-prompt.md. In scope:
- repo structure, schema, single-image container
- crypto module + tests
- signup / login / password change / recovery
- activity CRUD with strict visibility handling
- tag autocomplete (server
tagstable + client IndexedDB)
Explicitly out of scope for now:
- sharing/permissions beyond the three visibility levels
- comments, notifications, other social features
- native/mobile apps
- server-side full-text search over private data
- rate limiting on auth/recovery endpoints (defense-in-depth — the recovery verifier already closes the lockout-DoS hole; rate limiting reduces online brute-force surface)