medium convictionactive · updated 2026-08-21T00:00:00.000Z
User-owned graph primary → quota-aware YouTube candidates → rank without cloning browse
If the preference store is user-owned, the authoritative graph is local or in a user pod; YouTube candidates for known channels come from cheap playlistItems.list, not search.list; serving is still retrieve-then-rank and must not recreate YouTube browse.
The chain
1
A user-owned preference graph is stored as a device-primary or user-pod-primary replica; a cloud recs server is not the store of record.
From 2026-08-21-autoresearch-best-architecture-for-a-rec-system-web-app: "we treat the copy of the data on your local device … as the primary copy. Servers still exist, but they hold secondary copies."
From 2026-08-21-autoresearch-best-architecture-for-a-rec-system-web-app: "the application is not the store — the user (Social Agent) owns the pod and can switch applications"
2
YouTube catalog candidates for user-named channels are fetched via playlistItems.list on the uploads playlist (1 unit/page); search.list is a 100-call/day bucket and watch history stays closed.
From 2026-08-21-autoresearch-best-architecture-for-a-rec-system-web-app: "default project allocation is 100 search.list calls/day (own bucket, 1 unit per call including extra pages) … playlistItems.list, videos.list, channels.list, and subscriptions.list cost 1 unit each"
From 2026-08-21-autoresearch-best-architecture-for-a-rec-system-web-app: "The same method still returns watchHistoryNotAccessible / watchLaterNotAccessible — watch history is not a playlist you can page"
3
Serving remains retrieve-then-rank (optional on-device intent or test-time KG reason); recreating YouTube browse without significant independent value is forbidden.
From 2026-08-21-autoresearch-best-architecture-for-a-rec-system-web-app: "candidate generation first retrieves a subset of potential items … Scoring then ranks these candidates"
From 2026-08-21-autoresearch-best-architecture-for-a-rec-system-web-app: "must not recreate the browse experience from any YouTube Application without adding significant independent value to that flow"
What would falsify this
- Step 2: An official live watch-history API (not Takeout) appears with documented YouTube scopes — do not invent Data Portability.
- Step 3: A fetched reference architecture for a personal YouTube-first user-drawn-graph web app names and measures a single winning stack.
Contradictions / tensions
- Local-first, Solid, hosted PKB, and ODRS/hybrid are different ownership/compute answers; none is ranked as best for this use case.
- KGERA and K-RagRec reason over mined item KGs, not a hand-authored interest graph.
Implications
- A personal recs UI whose independent value is a user-drawn graph is the policy-shaped reason the app would exist; cloning homepage/Up Next is out.
- Graph-ownership auth (local-first / Solid) and YouTube OAuth/API keys are separate planes.
- This is a composition of cited constraints, not a fetched reference architecture that was built and measured.
Companies
Concepts
Local-first softwareMulti-stage rec servingOn-device recommenderYouTube data-access constraintsUser-owned interest graph
Open questions