FAMILY PHOTO FRAME — Docs

Status: DESIGN — COUNSEL-GATED. No code, no feed endpoint, no cross-product contract on either side until counsel clears the minors'-photo consent + access model below. The owner green-lit pursuing this (2026-07-18); "pursue" here means counsel does the minors' pass first (this doc is what they review), then build. Cross-product coordination via the crosstalk mesh; QS aligned on the architecture + the gate.

What it is (and the GTM)

A software-only family photo-frame / kiosk: a full-screen slideshow of a family's photos with the family calendar / next-routines overlaid, pointed at any old tablet or wall TV. GTM: undercut the hardware-bundled family screens (Skylight Calendar, Hearth Display, Cozyla — $150–300 box + subscription for {shared calendar + chore/allowance board + digital photo frame}) with a bring-your-own-tablet, software-only hub. QS reuses its shipped screensaver (the fireplace, idle-fade/reduced-motion/mobile-autoplay/battery-aware) as the display half; the owner-voice audio layer (HJ) is a differentiator the boxes can't match.

Display half SHIPPED — the Family Wall (2026-07-17, migration 518)

The non-photo half is built and merged: the "Family Wall" — a full-screen, token-scoped, read-only site (/family/wall/<token>) that runs on an old iPad / wall TV and shows the family's members + today's routines (name + emoji + done/pending). No photos, no birthdates → no counsel gate applies, so it shipped now. It deliberately builds the exact primitive the photo layer needs: a named frame → an unguessable, revocable, scoped feed token resolving server-side to a display-safe projection (projectWallView, which strips all PII). When counsel clears the photo model, the photo feed drops into this same page + token — the plumbing is already here. See INDEX.md "Family Wall" for files/endpoints/migration.

The photo layer below remains the counsel-gated part; everything above the photos (display, tokening, consent-scoped feed shape, revocation, liveness) now exists.

V1 scope — a full-screen SITE, no hardware (owner, 2026-07-17)

V1 is just a web page that runs full-screen on a device the family already owns — an old iPad in a stand, or an old laptop/mini-PC wired to a wall TV. Open the URL, hit full-screen / add-to-home-screen (PWA), leave it running. No hardware product, no device to ship, no firmware — that stays off the table for V1. The entire build is the display page + the (counsel-cleared) photo/consent plumbing behind it. Anything hardware-shaped (a bundled screen, a dedicated device) is explicitly out of scope until much later, if ever. This is the whole reason the GTM undercuts Skylight/Hearth: they sell a $150–300 box; we're a page on the glass you already have.

It is NOT greenfield — it rides HJ's existing family model

family_members (migration 075): parent-owned members with relationship (child/spouse/parent/sibling/other), a private birthdate shared only as an age-band, avatar, notes, kid-account linkage deliberately deferred, parent-only RLS. Uploads were explicitly deferred (avatar_emoji only) — so member photos are the net-new storage piece, on an existing minors-aware model.
Routines + check-ins per member (/api/family/members/:id/routines, /checkin) — already a chore / "keep tabs on them" board (half of Skylight).
JQ Bridge (migration 039) — the invite-based connection/oversight + hear-ACL layer. The Lovio loving-oversight rail.

So the frame is a media + display extension on a model that already treats minors carefully. Reuse the existing consent/scoping posture; don't reinvent it.

Architecture — two candidates for counsel (a′ preferred, a fallback)

Both keep QS renders-only. They differ on who custodies the minors' images — which is the pivotal legal fact, so counsel picks between them.

(a′) Parent-hosted share link — HJ/QS custody NOTHING (preferred, pending counsel). The parent shares their photos from their own iCloud Shared Album or Google Photos shared album and pastes the album link into the frame. HJ stores only the link (+ the parent's per-member EXPOSE consent + frame scoping); QS renders directly from the parent's album, caching nothing. The images never leave the parent's own Apple/Google account — the platform the family already trusts and that is already built for parent-controlled family sharing. This likely collapses the hardest legal exposure: HJ/QS are not storing or processing minors' images at all, just displaying a feed the parent owns and can unshare in one tap on Apple/ Google. Tradeoffs counsel must weigh: iCloud/Google album links are "anyone-with-the-link" (unguessable but not per-viewer-scoped) — mitigate by treating the link as a secret (never logged, never public, HJ-encrypted at rest, revoked = parent unshares); no server-side per-photo curation (parent curates in the album); dependency on Apple/Google album availability + link format. Revocation = parent unshares the album (instant, on their side) OR deletes the link in HJ.

(a) HJ-hosted originals — fallback if counsel prefers first-party custody. HJ hosts the originals in the secure member store; QuickSites renders from a SCOPED, SHORT-TTL, SIGNED feed of DISPLAY-SIZED DERIVATIVES, persisting NOTHING to disk (re-fetches on rotation). More HJ control (per-photo scoping, true signed short-TTL URLs, EXIF stripping) at the cost of HJ becoming the custodian of minors' images — the exposure (a′) avoids. Rejected regardless: QS holding originals (b) or down-rezzed cached copies (c) — "smaller copies of minors' faces on the sitebuilder's storage" is exactly what the §14 boundary exists to prevent.

Either way QS is renders-only; HJ owns consent + access enforcement (non-delegable). Counsel decides (a′) vs (a) — the storage-custody question below is written for both.

Principles proposed; counsel confirms/edits before any build:

Parent is the sole controller. Photos attach to a family_member (parent_user_id), parent-only RLS. Only the parent uploads, views, includes in a frame, or exposes via a feed.
Consent is explicit + layered, and separates VIEW from EXPOSE. A parent opting a photo into their own on-device frame (their screen, their data) is distinct from EXPOSING it via a cross-product feed QuickSites renders. The second is the sensitive step and needs its own affirmative, revocable consent per member (and possibly per photo).
The feed is device/display-scoped + ephemeral. A named frame → a scoped, short-TTL signed URL feed of display derivatives; instantly revocable (delete/toggle → feed 404s next fetch; QS caches nothing, so nothing to purge).
Deletion is real + immediate. Parent deletes a photo/member → originals + derivatives gone, feed stops serving. No orphaned copies anywhere (QS holds none).
Not public. The frame renders only on surfaces the parent explicitly points at (their tablet/TV); no public/indexable exposure; no third party beyond the QS render path the parent enabled.
Minors' faces are a step up from name+emoji. Inherit 075's caution (age-band-only sharing, kid-linkage deferred) and extend it deliberately.

Open questions FOR COUNSEL (must resolve before build)

Cross-product sharing of minors' images (HJ store → QS render): does it need anything beyond parent consent — a data-processing agreement between the two entities, a specific disclosure, a contractual "renders-only, no-retention" term binding QS?
COPPA applicability — parent-provided/parent-controlled photos vs "collecting personal info from a child." Where's the line for a display feed?
State biometric-privacy laws (e.g. Illinois BIPA) — do faces in stored photos + any future face-detection/tagging trigger biometric-consent regimes? (v1 does NO face detection — flag if that stays a hard line.)
GDPR/UK minors if ever offered there — lawful basis, parental consent age.
Kid-account linkage (075 deferred): if a minor later gets their own account, do they gain rights over photos of themselves? Design the toggle now or later?
Retention/deletion obligations + audit trail for a "delete everything" request.
Does architecture (a′) — parent-hosted iCloud/Google share link — materially reduce our obligations vs (a) HJ-hosted? If HJ/QS never store or process the images (only display a parent-owned album feed), does that move us out of "collecting/processing a child's personal info" for COPPA and out of custodian/ processor duties generally? What's the residual exposure from storing + rendering the link (an "anyone-with-link" album URL to minors' photos)? This is the question most likely to pick the architecture — flag it first.

Build plan — AFTER counsel clears (not before)

HJ (non-delegable), if (a′) share-link: store the parent's album link on the family_member (encrypted at rest, never logged/public) + per-member EXPOSE consent + a resolve endpoint that hands QS the parent-owned album feed; instant revocation (clear the link) + validation the link is a real iCloud/Google album. Consent UI on the family dashboard. No member-photo upload/storage pipeline — that's the whole point of (a′).
HJ, if (a) HJ-hosted (fallback): member-photo storage on family_members + upload (parent-only RLS, secure bucket, signed URLs) + the scoped display-derivative feed endpoint with per-member EXPOSE consent + TTL + instant revocation + hard delete + EXIF strip.
QS (renders-only): the kiosk/display UI (reuse the screensaver) rendering from the feed + the calendar/routine overlay; caches nothing; degrades to no-photo on any error.
Contract: crosstalk/contracts/family-media-feed.md — specified ONLY after counsel signs off (mirrors the memorial-voice-site gate: shaped, not authorized).

The gate (do not remove)

No member-photo storage, no feed endpoint, no QS render integration, no contract — until counsel signs off on the consent + minors' access model above. This doc shapes and prepares the counsel review; it does not authorize a build. The owner's "pursue it" started the counsel pass; counsel's clearance starts the code.

Family photo-frame — design + consent/minors' access-scoping spec