Cornerstone — photo intake (iCloud / Google Photos): the feasibility call

Status: ANALYSIS → recommendation (2026-07-31). Question (Sandon): should Cornerstone offer sync adapters to pull a family's photos from iCloud Photos and Google Photos into the vault? Demand instinct: people will want it (photos are the family's most precious data). Concern: it's a huge data store — unsure how it changes things.

Verdict up front: the demand is real, but "live-sync your whole library into our cloud" is the wrong shape on three axes at once. The right shape is import (not live sync) on the box (not our cloud), from the family's own export (not a platform API). The concern that "it changes things" is correct — and the thing it changes is which tier owns it.

The demand is real

Photos are the killer content for a family vault. A family's whole history sits in iCloud or Google Photos today — where Apple/Google can read it, scan it, train on it, and hold it hostage to a subscription. Cornerstone's entire pitch ("your data, sealed, only you can read it") is most compelling precisely about photos. So yes — offer something.

Why naive "upload your library to our cloud" is the wrong shape (three problems, compounding)

Scale/cost. Family photo libraries run 100s of GB to multiple TB (years of photos + video). Storing that per-family in our cloud (Supabase Storage / our B2) is an unbounded cost we'd be signing up for — the single most expensive content type there is.
Honest custody makes it maximally expensive. The vault is client-side encrypted, so we hold ciphertext — which cannot be deduped, cannot be compressed, cannot be thumbnailed server-side (that last one is literally the derived-data redline). So we'd store the full, unshrinkable ciphertext of every photo and video. The privacy guarantee and the storage bill fight each other, and the bill wins.
Story. "Move your photos from one big cloud that can read them (Apple/Google) to another big cloud (ours)" is a weak pitch even if ours is encrypted — so cloud ingest fails on story too. (And the right pitch turns out not to be "bring them home" either — it's additive, a copy that's yours; see the wedge read below.)

The resolution: photos are a BOX feature (your instinct was right)

Every one of those three problems evaporates on the home box:

Storage is the family's own disk (1–4 TB NVMe in the reference BOM) — zero per-family cost to us, and expandable by them.
Thumbnails, indexing, and search happen on-device over decrypted content — honest-custody compliant (the box is the client; no server-side plaintext shadow), and actually good (fast, private, offline).
Off-site backup is opt-in and family-paid (ciphertext → their own B2/Glacier) — the cost lands with the family who chose it, not on us for everyone.
The economics work: the photos live on the family's own disk — the only place a photo vault is affordable at all when honest custody means you can't dedupe or shrink the ciphertext.

So: don't offer cloud-tier photo ingest. Photo intake is a box capability. This is exactly what the box is for — and it's why the box isn't just "nice to have," it's the thing that makes "a family's photo vault" economically and architecturally honest at all.

Adapter feasibility — the maintainability treadmill (this is the part people underestimate)

Even setting scale aside, live API sync against these two platforms is a bad bet:

Google Photos. The Library API exists, but the 2025 restrictions cut third-party apps down to app-created content + a user-driven Photos Picker — you can no longer scrape a user's whole library programmatically. So "auto-sync the entire library" is blocked by policy, and Google has shown it will keep tightening. (Verify current policy before relying on any of it.) Any adapter is a rented capability Google can revoke.
iCloud Photos. There is no sanctioned third-party bulk-export API — full stop. The only real options are the user's own data export (below) or unofficial, reverse-engineered APIs (pyicloud-class) that break on every Apple change and put the user's Apple account (2FA, ToS) at risk. Not a supportable adapter.

Net: building live adapters against both is a maintenance treadmill against two hostile, shifting platforms — high ongoing cost, feasibility already partly blocked, for a small team pre-users. That's the trap the "it changes things" instinct is circling.

The honest, robust alternative: import from the family's OWN export

Both platforms let the user download their own full library — the sanctioned path:

Apple: privacy.apple.com → "Get a copy of your data" (includes Photos).
Google: Takeout → full Photos export.

Cornerstone imports from that export (a folder / archive), on the box, into local encrypted storage. This is:

Sanctioned — it's the user's own data export; no API ToS, no account risk.
Robust — a folder of files doesn't break when Google changes an API next quarter.
Honest — we never touch their iCloud/Google account or credentials; they hand us a folder.
On-brand — a copy of your photos that's genuinely yours, held where you choose (framed as an additive backstop, not a migration — see the wedge read).

Downside: it's periodic, not live-continuous. Acceptable — re-import (deduped on the box by content hash, which is fine on-device) catches new photos, and "sync my photos in real time" was never the actual need; "get my history off Apple/Google into something I own" is.

Recommendation

Don't offer cloud-tier photo ingest — the cost + story + honest-custody math all say no.
Do design photo intake as a BOX capability: import from Apple/Google exports → local encrypted storage; on-device thumbnails/search; opt-in, family-paid off-site backup.
Prefer import-from-export over live API sync. A live Google Photos Picker adapter (user picks specific albums/photos) is a low-priority maybe worth watching; iCloud live sync is a no (no sanctioned API).
Frame it as ADDITIVE, never migratory (QS cold read, 2026-08-01): "a copy that's yours" — a backstop — not "bring them home." The fear in this category is loss, not surveillance: Apple/Google are experienced as the trusted-durable place (the one that won't lose the baby pictures), so "move your only copy onto a box that can be dropped, burgled, flooded, or die on a Tuesday" fights the strongest feeling in the category. Insurance sells; a chore doesn't. Never ask a family to leave the place they trust with the originals.
Don't lead the box with photos at all — see the wedge read below.

The wedge, resolved (QS cold read, 2026-08-01): strong ATTACH, nice-to-have WEDGE

Don't build the box around photos. The acquisition wedge is event-driven — a death, a divorce, a locked-out account, a price hike, a ransomware scare, a new baby. "Nobody wakes up wanting a NAS; they want one the week after something frightened them." For a product called Cornerstone, the strong version is nearer "keeps your family's story after someone's gone" than "stores your JPEGs" — which is our Lovio / Cairn legacy thread, not a new pivot.
Photos are the ATTACH, not the acquisition: the reason the box is never unplugged (retention), not the reason it's bought.
Revealed preference is the decisive, unkind part. Consumer NAS (Synology/QNAP/Drobo) sold exactly "own your data, get off the cloud" to consumers for ~20 years and stayed enthusiast/prosumer — the longest revealed-preference experiment the category offers. People pay ~$2.99/mo indefinitely rather than perform the one-time migration they say, out loud, they want. Assume Cornerstone's buyer resembles that until proven otherwise (caveat: depends on price point + who the box is really for).
The testing trap to watch: personas WILL say they want their photos off the big clouds — everyone says that. The behavioural question that separates stated from revealed: "what did you do the last time Apple raised your storage price?" — past tense, not intent.

Open / verify

Current Google Photos API policy (exact scope of the 2025 Picker-only restriction).
Box import UX for a multi-hundred-GB library (progress, resumability, dedupe-on-device).
Whether a thin Google Photos Picker import (user-selected, sanctioned) is worth the small build as a convenience alongside Takeout import.
Video specifically — the biggest byte cost; possibly a "photos now, video later" split.