Research-only synthesis: cited web-app architecture patterns when the user owns the interest graph — layers, local-first vs hosted, sync, rec serving over a KG, candidate generation + ranking, auth/data ownership, and YouTube fetch constraints already known.

Autoresearch: best architecture for a rec-system web app on a user-defined interest graph

Generated by /autoresearch on 2026-08-21. Synthesized across 3 rounds from 12 web pages, anchored by Grokipedia Recommender_system. See Provenance. Treat as raw material — review before promoting into a project or thread. Context: vault/threads/interest-graph-recs

Research only. Not a product spec. Not graph-DB 101. No spark is cited.

Summary

Fetched sources compare several families of architecture for a personal recommender whose preference store is a user-owned graph. They do not name a single best stack for a YouTube-first web app. The load-bearing split is who holds the authoritative copy of the graph (local device vs cloud server vs user-controlled pod) versus where catalog retrieval and ranking run (on-device, cloud, or a hybrid: local intent / remote item fetch). Rec serving is consistently described as multi-stage — candidate generation, then scoring, then optional re-ranking or test-time knowledge-graph reasoning — even when the preference object is structured knowledge rather than an implicit-feedback matrix.

YouTube’s official API still bounds the catalog side: search.list lives in a 100-call/day bucket; playlistItems.list and videos.list cost 1 unit each; watch history is not retrievable; and Developer Policies forbid recreating YouTube browse without “significant independent value.” Those constraints already sit in this thread; this pass uses them as serving-layer facts, not as a new Data API survey.

“What is the best architecture…” therefore stays open. The fetched record supports a comparison of patterns, not a winner.

Findings

Rec serving is multi-stage even when the store is a knowledge graph

Grokipedia’s recommender-system primer (the anchor) splits operation into offline training on a sparse user–item matrix and online serving. Online serving is itself multi-stage: candidate generation retrieves a subset (hundreds from millions) via approximate nearest-neighbor search or similar cheap retrieval; scoring ranks those candidates; re-ranking then applies diversity, freshness, or business constraints (Grokipedia, Recommender system). That is the same two-stage family YouTube’s production papers use; this pass does not re-derive YouTube’s DNN internals.

Knowledge-based recommenders are a different preference model, not a different serving diagram. Grokipedia’s dedicated page says they use explicit domain knowledge (constraints, ontologies, elicited requirements) rather than a collaborative-filtering matrix, which addresses cold-start when interaction history is missing. User models can be feature–value pairs or graphs that link stated goals; item models are structured to match. The cost is knowledge engineering, not implicit-log scale (Grokipedia, Knowledge-based recommender system). A user-drawn interest graph sits closer to this family than to mined collaborative filtering.

Two fetched HTML papers keep the retrieve-then-rank split when a KG is in the loop:

KGERA (Scientific Reports) treats the KG as a test-time reasoner, not a training-time feature dump. A KG-Reason module scores each user–item pair at inference (~10 ms per user in their write-up) and a stacking ensemble fuses that score with ItemKNN, LightGCN, NCF, TransE, content, and popularity. The stated serving benefit is that the graph can change without retraining the base models. The graph they build is a mined six-relation item KG on MovieLens-1M (LIKES, HAS_GENRE, HAS_DIRECTOR, SIMILAR, COMPLEMENTARY, SUBSTITUTABLE) — not a hand-authored personal interest map (KGERA, Scientific Reports).
K-RagRec (arXiv HTML) indexes item-KG subgraphs into a vector store, applies a popularity-selective retrieval policy, re-ranks retrieved subgraphs, then projects them into an LLM for generation. Vanilla document RAG is called out as noisy and structure-blind. The candidate set (C) is still assumed to exist; the KG augments generation over that set (Wang et al., Knowledge Graph Retrieval-Augmented Generation for LLM-based Recommendation).

Neither paper is a personal-scale web-app blueprint. Both support the architectural claim that a rec API over a KG is retrieve → (optional structure reason / RAG) → rank, with the KG usable at serving time so the graph can be edited without a full retrain.

Who owns the graph: local-first, hosted PKB, or Solid pod

Local-first (device authoritative). Ink & Switch’s 2019 Onward! essay inverts the cloud contract: the copy on the user’s device is primary; servers hold secondary replicas for multi-device access. Cloud apps treat the server as authoritative and the client as a disposable cache — “you don’t have full ownership… the cloud provider does.” Local-first ideals: no server round-trip for reads/writes; work not trapped on one device (sync); network optional; collaboration without lock-in; long-term storage; security/privacy by default; user retains ultimate ownership. Sync foundations named there are CRDTs (Conflict-free Replicated Data Types), which merge concurrent edits over any channel (server relay, peer-to-peer, Bluetooth, USB). Automerge is their JS implementation; they do not claim it fully realizes the ideals (Ink & Switch, Local-first software).

PKB deployment taxonomy. Grokipedia’s personal-knowledge-base page names three hosting models: (1) local files (Markdown/JSON/RDF; Git-backupable; full ownership; slower query); (2) embedded/relational/graph databases (faster relationship query, schema evolution, more setup); (3) client–server (central host, multi-device; hybrid local-cloud stores primary data locally and syncs). Trade-offs listed: data sovereignty vs network dependence; concurrent-edit conflict protocols; API extensibility vs authentication burden (Grokipedia, Personal knowledge base). That is the cited menu for “how a user-defined KG sits behind a personal recs UI,” not a stack pick.

Solid (data independent of the app). The Solid Application Interoperability draft (Community Group Report, 25 September 2025) is not a W3C Standard. It specifies how Social Agents grant Applications access to data in a pod: identity profiles, registries, data registrations bounded by shape trees, access needs, and access authorizations. The architectural claim is that the application is not the store — the user (Social Agent) owns the pod and can switch applications; apps request typed access rather than ingesting a captive database (Solid Application Interoperability). For a user-owned interest graph, this is the cited alternative to “the recs web app hosts the graph.”

These three are in tension, not stacked: local-first makes the device replica authoritative; Solid makes a user-controlled web datastore authoritative and apps interchangeable; a hosted PKB makes the server authoritative (with optional export). No fetched source ranks them for a YouTube recommender.

Client vs server for ranking: cloud RS vs on-device vs hybrid

The WWW 2024 ODRS tutorial contrasts fully cloud-based recommenders (server trains on all hosted user data and pushes results) with on-device recommender systems. Cloud advantages: “infinite” compute for heavy models. Cloud costs they name: energy, network dependence, privacy. ODRS moves inference (and sometimes training) onto the device with locally stored user data. Industry instances they list: Taobao mobile, Google TensorFlow Lite Recommendation API, Kuaishou real-time short video, Brave’s built-in engine. Taxonomy: on-device deployment/inference, on-device training/update, privacy/security. Federated recommendation is called a subset of on-device training, not the whole paradigm (Yin, Chen, Qu, Cui, On-Device Recommender Systems).

RecGPT-Mobile (SIGIR 2026, Taobao) is a split architecture, not pure on-device ranking of a catalog. A local behavior store and on-device intent agent turn recent actions into an explicit query; an Item Retrieval Module then searches and “returns a set of interested items back to the client.” Related work they cite: EdgeRec (on-device ranking to cut signal latency); Kuaishou local feedback processing; DIR on-device re-ranking. They treat full-catalog retrieval as still a remote step because the item set is huge (RecGPT-Mobile). That split — local preference/intent, remote candidate fetch, optional local re-rank — is the closest fetched pattern to “user-owned graph + YouTube catalog.”

No fetched source tests that split on a user-drawn interest graph or on YouTube’s Data API.

YouTube fetch constraints as serving-layer facts (not a new API survey)

Official quota math, re-fetched this pass: default project allocation is 100 search.list calls/day (own bucket, 1 unit per call including extra pages), 100 videos.insert/day, and 10,000 units/day for everything else. playlistItems.list, videos.list, channels.list, and subscriptions.list cost 1 unit each (Quota Calculator).

Official candidate-generation path for a known channel is not search.list. Google’s playlistItems.list docs and App Engine samples resolve channels.list → contentDetails.relatedPlaylists.uploads → page playlistItems.list (maxResults 50, 1 unit/page). The same method still returns watchHistoryNotAccessible / watchLaterNotAccessible — watch history is not a playlist you can page (PlaylistItems: list; Python App Engine samples). Architecture implication: neighborhood-of-the-graph candidate gen that walks user-named channels/playlists is quota-cheap; keyword search.list per interest node is not.

Developer Policies (official, re-fetched): API Clients “must not… create, offer, or act as a substitute for, or substantially similar service to, any YouTube Applications” and “must not recreate the browse experience from any YouTube Application without adding significant independent value to that flow” (YouTube API Services - Developer Policies). 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. This pass does not invent Data Portability findings.

OAuth vs API key is also official in the samples: private user/channel data needs OAuth; public metadata can use an API key (Python App Engine samples). Graph ownership (local/Solid) and YouTube OAuth are therefore separate auth planes.

What this does not settle

No fetched page designs, measures, or crowns “the best architecture for a recommendation-system web app based on a user-defined knowledge graph.” KGERA and K-RagRec use mined item KGs. RecGPT-Mobile and the ODRS tutorial are industrial implicit-feedback systems. Ink & Switch and Solid address data ownership, not YouTube candidate retrieval. Knowledge-based recommenders describe explicit-constraint engines, not a personal YouTube loop. Property-graph vs RDF was not re-surveyed.

Contradictions and open questions

No winner. Local-first (device primary), Solid (pod primary, apps interchangeable), hosted PKB (server primary), and ODRS/hybrid (local rank or intent, remote catalog) are cited as different answers to ownership vs compute vs catalog scale. They are not ranked against each other for this use case.
User-drawn vs mined KG. Every fetched KG-rec architecture (KGERA, K-RagRec, Grokipedia’s KG-in-recs primer) assumes a constructed or item-side graph. A hand-authored interest graph is closer to knowledge-based / explicit user models, but those pages do not test YouTube.
Where ranking runs. ODRS and EdgeRec-style on-device ranking need a local candidate cache. RecGPT-Mobile keeps retrieval remote. YouTube quota + substitute-browse policy push toward caching cheap playlistItems of user-named channels and ranking locally — that composition is an inference from cited constraints, not a fetched reference architecture.
Auth planes. Solid/local-first govern the graph; YouTube OAuth/API keys govern the catalog. No fetched source specifies how a web app should compose those two.
Rec quality vs YouTube’s feed is a different question (can-a-user-owned-interest-graph-produce-better-recs) and remains out of this page’s verdict.

Provenance

Rounds run: 3 of 3

Sub-questions by round:

Round 1 (broad survey):

How do cited recsys architectures layer candidate generation, ranking, and a rec API when the preference store is an explicit/user-owned knowledge graph?
What documented architectures exist for local-first vs hosted personal knowledge graphs behind a web UI (sync, offline, data ownership)?
How do third-party YouTube-adjacent rec apps typically fetch and serve candidates given Data API / ToS constraints already known?
What auth and data-ownership patterns are documented for user-controlled graphs (Solid PODs, local-first sync, hosted-but-exportable)?

Round 2 (drill-down):

What do official YouTube Data API docs say about implementation patterns that would shape a personal recs serving layer? — targeting official quota / cheap-list vs search (vendor blogs deprioritized)
How do cited architectures split candidate generation (external catalog) from ranking over a user-owned preference object? — targeting ODRS / on-device vs cloud
What HTML KG retrieve-then-rerank papers exist after MDPI 403? — targeting K-RagRec as stand-in

Round 3 (resolve remaining uncertainty):

Confirm official Developer Policies substitute/browse language after a timeout — targeting the serving-layer policy bound
Confirm official playlistItems.list + samples as the cheap known-channel candidate path — targeting candidate-generation without search.list

Anchor source (Grokipedia, fetched before round 1):

Recommender system — 25,017 chars extracted (capped) — multi-stage serving (candidate generation → scoring → re-ranking); CF / content-based / hybrid; not a personal-KG web-app design.

URLs fetched (12 successful, 2 failed):

Round 1:

Local-first software (Ink & Switch) — official research essay — device-primary vs server-primary; CRDT sync
Solid Application Interoperability — official Solid CG draft — apps vs user-owned pods; access grants
~~[Failed: https://www.mdpi.com/2504-2289/6/1/11]~~ — 403 Access Denied (Query2Box KG candidate → NCF rerank paper)
KGERA (Scientific Reports) — peer-reviewed HTML — test-time KG reasoning + ensemble; MovieLens mined KG
Personal knowledge base (Grokipedia) — encyclopedia — file / embedded-DB / client-server PKB deployments
Knowledge-based recommender system (Grokipedia) — encyclopedia — explicit constraint/ontology recs; user models can be graphs

Round 2:

YouTube Data API Quota Calculator — official — 100 search.list/day; 1-unit list methods
~~[Failed (timeout, retried in round 3): https://developers.google.com/youtube/terms/developer-policies]~~
On-Device Recommender Systems tutorial — academic HTML — cloud RS vs ODRS taxonomy
K-RagRec — academic HTML — KG subgraph retrieve → rerank → LLM
RecGPT-Mobile — academic HTML — on-device intent + remote item retrieval (Taobao)

Round 3:

YouTube API Services - Developer Policies — official — no substitute YouTube app; no recreate browse without independent value
PlaylistItems: list — official — 1-unit list; uploads playlist pattern; watchHistoryNotAccessible
Python App Engine code samples — official — search.list vs channel-uploads via playlistItems.list; API key vs OAuth

Not fetched (by design): Neo4j vs RDF bake-off (already in thread). Off-whitelist PDFs (CEUR-WS Solid+PKG paper; Query2Box PDF; FedTREK-LM PDF). Vendor “innertube / no-quota” blogs (policy-incompatible as an architecture). Wikipedia (Grokipedia used). X (no --include-x).

Tools used: WebSearch, WebFetch, grokipedia-fetch (_lib/grokipedia.py). Generated: 2026-08-21 15:20 UTC