server/invites.ts derived the share URL from c.req.url — i.e., from
the API request's host. In production the API and SPA share an
origin so this happened to work; in dev where the SPA runs on :5173
and the API on :3000, the generated link pointed at the API
(http://localhost:3000/invite/<token>) which serves nothing.
Fix: the server no longer returns a `url` field. The token is the
canonical artefact; the SPA builds the share link itself via
`${window.location.origin}/invite/${token}`, which is always the
right origin regardless of split-process dev or single-process prod.
- shared/types.ts: InviteEntry.url removed
- server/invites.ts: drop originOf() and the URL field in toEntry()
- frontend Profile.svelte: new inviteUrl() helper; the displayed
<code> and the clipboard payload both use it
- tests/social.test.ts: assertion checks token shape instead of
the URL field
93 tests still pass.
Users can attach up to 5 labelled URLs to their profile — social
handles, blog, anything. They're shown on /<username>/list (the
opt-in public list), behind target="_blank" rel="noopener noreferrer
ugc" anchors so the destination tab can't script back into our
window.
Schema:
- user_links(id, user_id, label, url, position, created_at)
UNIQUE(user_id, position) to keep ordering stable, ON DELETE
CASCADE so user deletion sweeps links.
Wire:
- UserLink type (id/label/url)
- MeResponse.links: UserLink[]
- PublicListResponse.links: UserLink[]
- ProfileUpdateRequest.links?: { label, url }[] — bulk replace
- USER_LINK_LIMITS exported so frontend constraints match server
Validation (server/auth.ts):
- Label 1-40 chars, trimmed
- URL parseable + http:// or https:// only (no javascript:, data:,
mailto:, etc.)
- URL ≤ 500 chars
- Max 5 links per user
Bulk replace semantics with up-front validation, then DELETE +
INSERT inside the same transaction as the user UPDATE. A username
UNIQUE violation rolls back the link changes too — no half-applied
state. Empty rows in the request are silently dropped so users
can leave half-typed entries without a server rejection.
Frontend Profile gets an "Eksterne lenker" section between the
FriendsPanel and the Eksporter section. Five label+URL row pairs
with add/remove buttons, save button, error → Bokmål mapping
(link_label_required, link_url_bad_protocol, etc.).
93 tests still pass; typecheck clean; build ok.
The intro paragraph that names the visibility levels skipped over
"friends" — which is now a first-class visibility, not a footnote.
Added "Du kan også dele ting med vennene dine." so visitors learn
about the option as part of the welcome.
Playwright inspection of the redesigned root page surfaced three real
issues:
1. The .landing-hero element had a bottom-border that rendered as a
harsh horizontal rule between the intro and the search. Combined
with the footer's top-border, a short landing page had TWO visual
<hr> lines fighting each other. Removed the bottom-border.
2. The intro's secondary paragraph ended with "Mer om personvern og
hvordan det virker." — the persistent footer right below has the
exact same link. Two identical CTAs within ~400 vertical pixels
on a short page. Dropped the inline link.
3. **Real contrast bug**: the body's snowflake background image was
meant to be barely-visible (a body::before wash at z-index -1 was
supposed to fade it). But `z-index: -1` on a pseudo-element of
body puts it BEHIND the body's painted background — not in
front. So the wash did nothing, and on full-screen viewports
(≥1100 px) the snowflake rendered at full luminosity-blended
opacity, wrecking text contrast. The user spotted this in full
screen.
Fix: remove the body-background snowflake entirely. The ❄ glyph
next to the wordmark in nav.top h1::after already carries the
seasonal icon language and never interferes with content text.
Also: extended .gitignore to drop .playwright-mcp/ artefacts and
*.png. The previous attempt at this commit accidentally included
inspection screenshots and console logs; reset and redone.
The previous palette was technically correct (passed WCAG, worked in
both themes) but read like a generic Linear/Notion clone. The new
look leans into "doing things in winter with people" — warm orange
accent, beige borders, a snowflake glyph next to the wordmark, soft
shadows on cards that lift on hover.
Palette (all combos verified for ≥4.5:1 contrast in both themes):
Light: bg #f8f5ef, fg #1a1612, accent #c2410c (orange-700),
border #e5dfd3, card #ffffff
Dark: bg #14110d, fg #f0ede5, accent #fb923c (orange-400),
border #2d2820, card #1d1813
Visibility colours now live in their own variables (--vis-private,
--vis-semi, --vis-public, --vis-friends) decoupled from --accent, so
the brand hue can change without making "private" look like a
primary action.
Cards:
- radius bumped 10→12 px, padding +10%
- subtle shadow base (--shadow-sm), with --shadow-md on activity
row hover so the cards feel tactile
- article.card:hover gets a hint of accent in the border
Buttons:
- Primary button gains a 1 px lift + larger shadow on hover (only
on the primary — secondary buttons just tint to accent-soft)
- All buttons keep min-height: 44 px (WCAG 2.5.5)
Visibility badges:
- Each gains an emoji glyph via ::before (🔒/🎭/🌍/👥), so meaning
isn't conveyed by colour alone (a11y win, also faster scanning)
- Use color-mix() for backgrounds — cleaner than per-rgba tuples
Hero on the landing page:
- New .landing-hero block: bigger first paragraph (1.05 rem,
--fg colour), softer secondary line, bottom-border divider so
the section reads as a hero rather than two muted paragraphs
Decoration:
- On viewports ≥1100 px, the page background gets the icon SVG
fixed at low opacity (luminosity blend mode + a body::before
wash, so it's barely-visible — never competes with text contrast)
- Wordmark gets a small ❄ accent next to it
Theme-color meta + manifest + icon SVG fill all updated to match.
prefers-reduced-motion still disables transitions and the primary
button lift.
CSS grew from 3.65 → 6.38 KB (2.05 KB gzipped); no other bundle
changes. Typecheck clean.
Tag pills in ActivityRow now navigate to /tags/<tag> when clicked.
The destination shows every activity matching the tag that the
viewer would otherwise be able to see — same visibility rules as the
dashboard: anonymous gets public + semi, authenticated adds own
private + friends-only.
Design choice: client-side filter, no new server endpoint. The
dashboard's `GET /api/activities` already returns exactly the rowset
that should be filterable by tag, so TagPage.svelte loads the list
the normal way and runs `.tags.includes(needle)` on it (private rows
decrypt locally first — same pattern Home.svelte uses for search).
Avoids duplicating the 4-clause visibility filter SQL into a second
endpoint, and the private-tag case wouldn't have worked on the
server anyway since private tags are inside the encrypted payload.
Routing:
- parsePath gains `/tags/:tag` with decodeURIComponent for any
character (tags allow spaces, special chars, etc — they're
normalised server-side to lowercase + trim)
- applyRoute branch sets view='tag' and tagName from the URL
- leaveTag() returns to /home (logged in) or / (logged out)
- Nav header is hidden on the tag view (it has its own back button,
same pattern as PublicList and ActivityPermalink)
ActivityRow tag pills changed from <span> to <a href="/tags/...">,
inheriting colour and dropping text-decoration so the visual pill
stays as-is. The :focus-visible underline added in commit 6313f36
still applies, so keyboard users see focus clearly.
Also, while in profile copy: removed the stale "delen av eposten din"
hint in Profile.svelte — the email-prefix fallback was removed in
commit 43c24ec, the docstring lagged. New copy: "Er feltet tomt og du
har satt et brukernavn, brukes det i stedet. Ellers vises ingen
attribusjon."
Typecheck clean; build succeeds.
"venner-bare-innhold" and "venner-bare-oppføringer" are
awkward compound coinages — Norwegian prefers a postpositional
"X for venner" ("content for friends"). Two instances + one in the
"hvem får se mine ..."-liste fragment, all updated.
Surfaced by a copy review.
A fourth visibility level ("Venner") with one-way friendship and
two-way block filtering, plus the table-rebuild migration that drags
older dev DBs forward.
Visibility model:
- Friendship is directional: (owner, friend) means owner has added
friend to their list. Owner's friends-only activities become
visible to friend; friend isn't automatically friends with owner.
- Blocking is also directional at the DB level (blocker, blocked)
but is checked SYMMETRICALLY at visibility-resolution time: once
either user has blocked the other, friends-only content stops
flowing in either direction. Block does NOT affect public or
anonymous content — those are open to anyone by definition.
- "Friends-only" is an access-list visibility, NOT cryptographic.
The server stores the content in plaintext and serves it only to
authorised viewers. This is documented honestly in /personvern.
Schema:
- activities.visibility CHECK gains 'friends' as a fourth value
- friends(owner_id, friend_id, created_at) — composite PK,
self-friending blocked by CHECK
- user_blocks(blocker_id, blocked_id, created_at) — same shape,
blocking-self also blocked
Migration (server/db.ts):
- SQLite can't ALTER a CHECK constraint, so the migration detects
out-of-date DBs by scanning sqlite_master for the literal
"'friends'" in the activities table's CREATE statement
- If absent, rebuilds activities via the standard SQLite
table-copy-drop-rename dance with foreign_keys briefly off
around the transaction, then runs foreign_key_check to confirm
no FKs were left orphaned (activity_tags, activity_hearts,
bookmarks all point at activities). Smoke-tested on the dev DB:
olemd's user row and moderator/admin flags survived.
Server endpoints (server/friends.ts):
GET /api/friends — my outgoing list
GET /api/friends/incoming — who has added ME
POST /api/friends — add by username (idempotent)
DELETE /api/friends/:userId — remove a friend
GET /api/friends/blocks — my blocked-users list
POST /api/friends/blocks — block by user_id (idempotent)
DELETE /api/friends/blocks/:userId — unblock
Add-by-username (not by email): users must set a username to be
findable. Email stays a private contact identifier.
Activity list filter (server/activities.ts): adds two clauses to the
WHERE — own friends-only, and friends-only owned by a user who has
added me AND there's no block in either direction. Single-activity
GET applies the same check.
Frontend:
- ActivityForm.svelte gains the "Venner" option
- ActivityRow.svelte renders a "Venner" badge with a new amber
vis-badge.friends colour (passes contrast in both themes)
- FriendsPanel.svelte: add-by-username form, outgoing, incoming
(with Block button), and blocked (with Unblock button)
- Profile.svelte mounts FriendsPanel between display fields and
Eksporter
- Home.svelte adds a "Venner" section between private and semi
Docs: Personvern.svelte gains a "Venner og blokkering" section
explaining that friends-only is access-list-not-crypto and pointing
the reader at "private" for actually-sensitive content.
26 tests still pass; typecheck clean; build succeeds. Bundle
36.8 KB → 39.1 KB gzipped (FriendsPanel + new server endpoints +
the Personvern prose).
Two layers of explanation, addressing the gap between "I just want to
use it" and "I want to understand the crypto."
Inline:
- Signup page: extends the existing one-liner with a "Les hvordan
det virker" link. Opens in a new tab so the user doesn't lose the
form (and any invite token) mid-read.
- Public landing: gains a second muted paragraph that names the
three visibility levels in plain language and links to the docs.
Detail page (/personvern):
- New Svelte component Personvern.svelte with sections for the
three visibility levels, E2E key model, password vs recovery
code, what the server stores vs doesn't, sessions, and explicit
limits ("what crypto does NOT protect against").
- Written for non-technical users; still names the primitives
(Argon2id, XChaCha20-Poly1305) and gestures at SECURITY.md for
anyone who wants the engineering depth.
App.svelte routing:
- New /personvern path handled in parsePath
- applyRoute branch sets view='personvern'
- leavePersonvern() routes back to /home or / depending on auth
- Persistent footer link on every view so the docs are always one
click away
Norwegian Bokmål throughout. No new dependencies. Bundle 34.2 KB →
36.8 KB gzipped (mostly the markdown-ish prose content).
The "Du registrerer deg med en invitasjonslenke" banner that appears
when arriving at signup via /invite/<token> was a plain <div> — a
screen reader would read it in document order with no special
treatment. role="status" turns it into a polite live region so AT
users hear it as a contextual announcement when the signup view
loads with an invite attached.
Surfaced by /audit a11y (semantic structure lens).
Without scope="col", screen readers can't reliably associate each
header cell with its column when the user is navigating cell-by-cell.
Modern AT often guesses correctly from <thead> placement, but the
explicit attribute removes the ambiguity.
One attribute per <th>, no rendering change.
Surfaced by /audit a11y (semantic structure lens).
Activity title permalinks and the "Vinterliste" nav logo are styled
with color: inherit; text-decoration: none — perfect for a clean
visual, but they relied on the generic *:focus-visible outline to
signal focus. The outline alone is easy to miss against the activity
card border, and a low-vision keyboard user has no underline cue to
fall back on.
Added an a:focus-visible rule with a slightly larger outline-offset
and an underline. Standard anchors (the OSM links, the public-list
attribution links) already had their accent colour AND now get the
underline on focus too — all wins, no regressions.
Surfaced by /audit a11y (keyboard & focus lens).
App.svelte already renders <h1>Vinterliste</h1> in the nav, so the
PublicList page's <h1>{displayName || username}</h1> produced a
two-h1 document — screen-reader users navigating by headings would
see two top-level entries that aren't actually peers.
Switched to <h2>, kept the larger font size inline so the visual
hierarchy is unchanged. Every other view (Home/Profile/Admin/Feedback)
already follows the "nav h1, view h2" pattern; this brings PublicList
in line.
Surfaced by /audit a11y (semantic structure lens).
The previous text ("Offentlige og halv-offentlige aktiviteter. Logg
inn for å se og legge til dine egne.") read like a sysadmin status
banner — it described the data model rather than the purpose.
New text explains what the app is actually for: making and sharing
winter activity lists to keep the winter blues at bay, with a nod to
the fact that some users will use it for entirely different lists.
Login is still one click away in the nav, so the dropped "Logg inn
for å se …" instruction isn't needed.
A new "Eksporter" section on the Profile page generates a markdown
file containing all activities visible to the caller — including
their own private ones — and triggers a download.
Why pure client-side:
- Private rows are E2E-encrypted; the server doesn't have the
cleartext. Decryption MUST happen in the browser.
- Avoiding a server endpoint also means there's no "give me my
plaintext" target for anyone who steals a session cookie.
Mechanics (frontend/src/lib/export.ts):
- Fetch /api/activities (same as the dashboard does)
- For each row, normalise: decrypt private payload via session.dek,
pass semi/public through as-is
- Build a markdown doc with sections "Private (N)" and
"Offentlige og anonyme (N)" plus per-row title/description/tags/
location/scheduled blocks
- Wrap in a Blob, create a temporary <a download>, click it, revoke
the object URL
The Profile section reports the resulting size as a quick confirmation
and surfaces errors inline. No server changes required.
Bundle: 32.7 KB → 34.2 KB gzipped (mostly the export helper itself,
which is plain string concatenation — no new deps).
Logged-in users can star a public or semi activity to save it for
later. Bookmarked rows float to the top of the user's dashboard in a
dedicated "Bokmerker" section. The same row still appears in its
visibility section below — bookmarking doesn't remove anything; it
just adds a fast lane.
Schema:
- bookmarks(user_id, activity_id, created_at) with composite PK
- Both FKs CASCADE so user deletion or activity deletion sweeps
bookmarks automatically
Wire/types: ActivityPublic/Semi/Private all gain `viewer_bookmarked:
boolean` for type uniformity. Private rows always carry false (the
owner already has direct access; bookmarking own private items would
be redundant), and the bookmark endpoints reject visibility='private'
with cannot_bookmark_private. Anonymous viewers (public-list endpoint)
get false too.
Server:
- viewerBookmarked() helper next to heartsFor() — same shape
- serialize() includes the field
- POST/DELETE /api/activities/:id/bookmark, idempotent via
INSERT OR IGNORE / DELETE; mirrors the heart endpoints
Frontend:
- ActivityRow gets an "☆ Bokmerk" / "★ Bokmerket" toggle next to
the heart button. Uses the same optimistic local-override pattern
so the UI feels instant.
- Home renders a "Bokmerker" section at the top when bookmarked
rows exist. publicOnly mode (the "/" landing) skips it — the
field is always false there.
26 tests still pass; typecheck clean.
A free-text body alongside title/tags/location/scheduled. Plain text
for now; markdown rendering is a deliberate non-goal (the user noted
it was nice-to-have but not essential).
Schema (additive, idempotent via ensureColumn):
- activities.description TEXT NULL
- For private rows the column stays NULL; the description lives
inside the encrypted payload alongside title.
Wire/types:
- PrivatePayload.description?: string (in shared/crypto.ts)
- ActivityPublic.description / ActivitySemi.description: string | null
- CreateActivityRequest.description?: string | null
Server:
- INSERT and UPDATE handlers now write description for semi/public
- Private→semi/public transition: description column populated
- Semi/public→private transition: description column wiped (now in
the encrypted blob)
- serialize() includes the column on public and semi rows
- server/users.ts public-list endpoint surfaces it too
Frontend:
- ActivityForm.svelte: textarea after the title field; round-trips
through the existing private-encrypt / plaintext-PATCH paths
- ActivityRow.svelte: renders the description as a `white-space:
pre-wrap` <p> so line breaks survive without enabling markdown
- Home.svelte: search now matches against the description text
(decrypted client-side for private rows, just like the title)
The owner attribution helper used to fall back from display_name to
the part of the email before "@" when no display name was set. That
defeats the point of letting users pick a name: anyone who hadn't
explicitly chosen one had their email prefix surfaced publicly.
New fallback chain, applied uniformly:
- display_name (the user's chosen name) — if set, use it
- username (also chosen by the user as a URL slug) — if set, use it
- null — render nothing; the client hides the attribution line
Wire type ActivityPublic.owner_display is now `string | null`.
ActivityRow renders the "Lagt til av X" line only when display is
non-null.
Same idea applied to the user's own surfaces (nav + greeting):
- Nav button shows "Profil" (a label, not a name) when display_name
is empty, instead of falling back to the email.
- Home greeting drops "Velkommen, <name>." entirely when the user
has no display name, leaving just "Her er aktivitetene dine ...".
The feedback list (moderator view) and admin user table keep showing
the email — moderators and admins legitimately need it to identify
users for triage and role management.
Three pieces of a single registration story.
1. **Self-registry toggle.** New generic `settings` key/value table.
Initial key: `self_registry_enabled` (default `1`). Admin-only PATCH
/api/settings flips it. GET /api/settings is public so the login
screen can hide the "Opprett konto" CTA when registration is closed.
2. **Invite links.** New `invites(token, inviter_user_id, created_at,
claimed_at, claimed_by_user_id)` table; tokens are 22-char base64url
(~128 bits of entropy). Endpoints:
POST /api/invites — create (any logged-in user)
GET /api/invites — list mine
DELETE /api/invites/:token — cancel an unclaimed invite
Claimed invites are kept in the DB (the audit trail of who-invited-
whom survives) — only unclaimed ones can be cancelled.
The signup endpoint accepts an optional `invite_token`. The signup
handler does the claim + user-insert in a single SQLite transaction
so we can't end up with a claimed invite pointing at a missing user.
A concurrent claim race is closed by `UPDATE … WHERE claimed_at IS
NULL` — only one transaction's UPDATE actually flips the column.
New `users.invited_by` column records the inviter id so accounts have
a traceable origin. Profile page shows the user's invites with
"Kopier lenke" / "Avbryt" buttons; the SPA serves /invite/<token>
into the Signup view with the token prefilled.
3. **First-user auto-admin.** The signup handler counts users *before*
the insert; if it's the first one, `is_admin` is set on the row.
This solves the bootstrap chicken-and-egg without an env var or
sqlite3 step. Documented in README.
When self-registry is **off**:
- The login screen hides "Opprett konto" and shows a "stengt" notice
- /api/auth/signup with no invite returns 403 signup_closed
- /api/auth/signup with a valid invite still works (and attributes)
- /api/auth/signup with an *invalid* invite returns 403 invalid_invite
When self-registry is **on**:
- Anyone can sign up (no invite required)
- An invite that comes along is still consumed for attribution
- An invalid invite is ignored — signup proceeds without attribution
26 tests still pass; typecheck clean; bundle 31.2 KB → 32.7 KB gzipped.
Three small features and one UX bug.
1. **Hearts.** New `activity_hearts(activity_id, user_id, created_at)`
table with composite PK. POST/DELETE /api/activities/:id/heart for
logged-in users on any non-private activity. Idempotent — re-posting
is a no-op rather than a 409.
Activity serialisation now includes `heart_count` and
`viewer_hearted` on all three visibility variants (private is always
0/false; hearts make no sense there). ActivityRow renders a toggle
button with optimistic updates and a local override that snaps back
on network error, then propagates the server's authoritative state
to the parent list via a new `onChanged` callback.
2. **Admin can triage feedback.** Added `done_at` + `done_by` columns
to feedback (migrated via ensureColumn for older scaffold DBs). New
admin-only endpoints:
PATCH /api/feedback/:id — { done: boolean }; sets/clears done_at
DELETE /api/feedback/:id — drops the entry
The Feedback list view sorts open requests above done ones, and
admins see "Marker som ferdig" / "Marker som åpen" / "Slett" buttons
per entry. Open/done badges visible to everyone with read access
(i.e., moderators).
3. **Clicking an activity opens its permalink.** Activity titles in
ActivityRow are now anchor links to /a/:id, so clicking the title
navigates to the permalink view. Action buttons (heart, edit,
delete, del/copy-link) stay inside the card; the anchor only wraps
the title text, so taps elsewhere don't navigate.
Bundle gained 1 KB gzipped (30.2 → 31.2 KB). 26 tests still pass,
typecheck clean.
Three related changes.
1. **Admin role.** New `is_admin INTEGER NOT NULL DEFAULT 0` column on
users; added to MeResponse. Admin strictly implies moderator —
shared/roles.ts has a single isModerator()/isAdmin() pair so the
implication can't drift between callers. The duplicated isModerator()
helpers in server/activities.ts and server/feedback.ts now import
from there.
/api/admin endpoints (admin-only):
GET /admin/users — list users with their roles
PATCH /admin/users/:id/role — set is_moderator and/or is_admin
Last-admin guard: the role-update endpoint refuses to demote the only
remaining admin (409 cannot_demote_last_admin). Bootstrap is via
`sqlite3 ... UPDATE users SET is_admin=1` — documented in README.
Frontend Admin.svelte: table of users with toggles for moderator and
admin. Visible from the nav only when the current user is admin.
Toggling our own role refreshes session.user so the nav adapts
immediately.
2. **Root/home split.** The URL `/` always shows the public landing
(public + semi activities), even when the user is logged in. `/home`
is the authenticated dashboard. After login or signup the SPA pushes
`/home`; after logout it pushes `/`. popstate is wired so the
back/forward buttons work. Unknown paths fall through to the public
landing, not a 404.
3. **Activity permalinks at /a/:id.** New SPA route renders a single
activity via the existing GET /api/activities/:id endpoint (private
rows still require the owner's session to decrypt). A "Del" button
on each ActivityRow copies the absolute permalink to the clipboard.
Clipboard API has a prompt() fallback for environments where it's
blocked.
Server changes minimal: server/admin.ts is the new file; server/roles.ts
is the lifted helper; server/index.ts wires the admin routes; server/db.ts
gets one more ensureColumn() line.
26 tests still pass; typecheck clean; Vite build succeeds. Bundle grew
from 28.6 KB gzipped to 30.2 KB reflecting the Admin + permalink views.
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.
opt-in /<username>/list, and a feedback channel
Six related features that touch the user model and activity UX:
1. **User profile** (display_name, username, public_list_enabled).
New `display_name`, `username` (UNIQUE, slug-shaped), and
`public_list_enabled` columns. PATCH /api/auth/profile is a partial
update — pass only the fields you want to change, null to clear.
MeResponse exposes all three. Display name is shown on public
activities and in the nav; falls back to the email prefix when
unset.
2. **Change password from the profile editor.** Existing
/api/auth/password endpoint surfaced in the new Profile.svelte;
the local-decrypt failure path on a wrong current password is
mapped to a clean error.
3. **Edit existing activities.** ActivityForm becomes dual-purpose
(create or edit). Title, tags, date/time, location, and
visibility are all editable. Visibility transitions decrypt or
re-encrypt client-side as needed before PATCH, and the IndexedDB
private-tag index is kept in sync diff-style.
4. **Search.** A search input on Home filters across visible
activities. Private rows are searched against their decrypted
cleartext (decrypted once and memoised via $derived, so the work
is amortised across keystrokes). Matches across title, tags,
location label, and (for public) author display name.
5. **OpenStreetMap links.** Each row with a location renders the
label as an OSM link. Smart: coords if present
(?mlat=&mlon=&map=15/lat/lng → pinned view), else
/search?query=. Built with the WHATWG URL constructor so
Norwegian characters and commas survive.
6. **Moderator role + semi-delete by owner.** New is_moderator
column on users. Owners always delete their own rows; moderators
can additionally delete any semi or public activity (private is
excluded — it's invisible to others, so there's no moderation
case). README documents the manual promotion via sqlite3.
7. **Opt-in /<username>/list.** New server route
/api/users/:username/list returns the user's public activities
when both `username` is set AND `public_list_enabled = 1`. 404
when either condition fails — same response in both cases so the
route doesn't leak username existence for users who haven't opted
in. SPA-side, App.svelte parses window.location.pathname on
mount; falls back to "/" via history.replaceState after
authenticating from a deep link.
8. **Feedback channel.** New `feedback` table. POST /api/feedback
for any authenticated user; GET /api/feedback gated to
moderators. The Feedback.svelte component is dual-mode — the
form is universal; the list view auto-loads only for
moderators. Submitter identity (email + display name) is shown
to moderators so they can follow up; not exposed to the
submitter themselves.
Schema migrations land via the existing ensureColumn() helper so
scaffold DBs upgrade cleanly. The username UNIQUE constraint is
applied as a partial unique index (WHERE username IS NOT NULL) so
multiple users with NULL usernames don't collide.
All 26 existing tests still pass; typecheck clean for both
tsconfigs; Vite build succeeds.
The original spec stored only `kek_salt`, `wrapped_dek_pw`+nonce,
`rec_salt`, and `wrapped_dek_rec`+nonce. Under that model, anyone who
knew a user's email could POST to /auth/recovery-complete with junk
material and overwrite the password-side wrap, locking the legitimate
user out. The data stayed safe (the attacker couldn't decrypt
anything) but the account was effectively DoS'd until the user dug up
their recovery code.
Fix: add a recovery-side verifier mirroring the password-side one.
Storage: two new columns on `users`:
- rec_auth_salt BLOB NOT NULL — independent of rec_salt
- rec_auth_verifier_hash TEXT NOT NULL — Bun.password.hash output
The migration adds them via ensureColumn() for forward-compat with
scaffold DBs that pre-date this commit; new tables get them via the
CREATE TABLE statement.
Wire protocol:
- SignupRequest gains rec_auth_salt + rec_auth_verifier
- RecoveryChallengeResponse gains rec_auth_salt
- RecoveryCompleteRequest gains rec_auth_verifier
Server (server/auth.ts):
- signup hashes the recovery verifier alongside the auth verifier
and stores both
- recovery-challenge returns rec_auth_salt so the client can derive
the verifier; refuses with 409 for pre-fix accounts that have a
NULL rec_auth_salt
- recovery-complete calls Bun.password.verify against the stored
hash BEFORE touching any state. Always runs verify even for
unknown emails (against a dummy hash) so timing doesn't leak
existence — same pattern we already used for /auth/login.
Client (frontend/src/lib/auth.ts):
- signup() generates a fourth salt and derives the recovery
verifier from the recovery code
- recover() fetches the new rec_auth_salt and submits the derived
verifier as part of recovery-complete
Recovery.svelte distinguishes the new 401 ("Feil gjenopprettingskode")
and 409 ("Denne kontoen mangler gjenopprettingsverifikator") cases.
Regression test (tests/auth.test.ts) asserts the gate is real:
- junk recovery verifier → 401, no state changes
- unknown email → 401 (constant-time)
- challenge response includes rec_auth_salt
- correctly-derived verifier passes the gate
SECURITY.md is updated to describe four salts instead of three, the
new key-model storage, and the closed lockout DoS. CLAUDE.md flags
the rec_auth_* columns as load-bearing — removing them re-opens the
hole.
This is the only deviation from the spec's stated storage model;
documented as such in both SECURITY.md and CLAUDE.md.
Foundation for an E2E-encrypted activity list per
winter-list-claude-code-prompt.md.
Server (Bun + Hono):
- bun:sqlite with WAL and the spec's schema (idempotent migration)
- opaque server-stored sessions, httpOnly cookie
- signup / challenge / login / logout / me / password / recovery-challenge /
recovery-complete
- activity CRUD with strict visibility rules: private uses ciphertext+nonce,
semi never serializes owner_id, public attributes the owner
- tag store with normalisation + autocomplete (semi/public only)
Frontend (Svelte 5 + Vite):
- libsodium-wrappers-sumo for client crypto (Argon2id + XChaCha20-Poly1305).
SUMO is required because the standard build omits crypto_pwhash.
- IndexedDB-backed private tag index (never leaves the browser)
- in-memory DEK (no localStorage); page reload re-prompts for password
- signup shows the recovery code once; tag input merges server + private
sources with clear labelling
- Bokmål UI
Crypto module (shared/crypto.ts):
- pure, runs in both Bun and the browser via a runtime-conditional loader
that papers over libsodium-wrappers-sumo's broken ESM entry (createRequire
on server, Vite alias in the browser)
- DEK wrap/unwrap, AEAD payload encryption, recovery code generation with
a visually-unambiguous alphabet
Verification:
- 22 crypto round-trip tests (wrap/unwrap, AEAD tamper rejection, password
change preserves ciphertexts, recovery still works after rotation)
- typecheck passes for server and frontend
- Vite production build succeeds; libsodium SUMO chunk is ~315 KB gzipped
Single-image Containerfile for podman: builds frontend in a builder stage,
runs Bun in a slim runtime; one volume for the SQLite file; BUILD_DATE /
GIT_REVISION baked into OCI labels and /etc/build-info.
Known limitation deferred for this commit: the recovery endpoint has no
server-side proof of the recovery code (anyone who knows an email can lock
out the legitimate user, though they can't read any data). Closed in the
next commit.
