What web-app architecture fits a user-owned interest-graph recommender?

The question

What is the best architecture for a recommendation-system web app based on a user-defined knowledge graph?

Why it matters

SCOPE’s architecture claim, distinct from can-a-user-owned-interest-graph-produce-better-recs (rec quality vs YouTube’s feed). This page asks how a personal-scale web app would typically be layered when the user owns the graph: client vs server, local-first vs hosted, sync, rec serving over a KG, candidate generation + ranking, auth / data ownership, and the YouTube fetch constraints already known. Not graph-DB 101 and not a product.

What we currently believe

Fetched sources compare architecture families. They do not name a winner for a YouTube-first personal recs web app. Ownership of the graph and placement of ranking are separate axes: device-primary (local-first-software / ink-and-switch), pod-primary (solid-project), or hosted PKB (server-primary); ranking may be cloud, on-device (on-device-recommender), or split (local intent, remote catalog fetch). Rec serving is consistently multi-stage-rec-serving — retrieve, then rank, optional test-time KG reason — even when the preference object is structured knowledge (knowledge-based-recommender). YouTube’s official cheap candidate path is playlistItems.list on named-channel uploads, not a search.list loop; browse-clone is policy-barred. From 2026-08-21-autoresearch-best-architecture-for-a-rec-system-web-app. See user-owned-graph-to-quota-aware-youtube-serving.

Evidence we have

• From 2026-08-21-autoresearch-best-architecture-for-a-rec-system-web-app: Ink & Switch — local replica primary, server secondary; CRDTs for sync over any channel.
• From 2026-08-21-autoresearch-best-architecture-for-a-rec-system-web-app: Grokipedia PKB deployments — local files vs embedded/graph DB vs client–server / hybrid local-cloud.
• From 2026-08-21-autoresearch-best-architecture-for-a-rec-system-web-app: Solid SAI draft — apps request typed access; the user owns the pod and can switch apps.
• From 2026-08-21-autoresearch-best-architecture-for-a-rec-system-web-app: ODRS tutorial — cloud RS vs on-device inference/training; RecGPT-Mobile (Taobao) splits on-device intent from remote item retrieval.
• From 2026-08-21-autoresearch-best-architecture-for-a-rec-system-web-app: Online serving is candidate generation → scoring → re-ranking; KGERA adds test-time KG reasoning (~10 ms) on a mined MovieLens item KG; K-RagRec retrieves then re-ranks item-KG subgraphs for an LLM.
• From 2026-08-21-autoresearch-best-architecture-for-a-rec-system-web-app: Knowledge-based recommenders use explicit constraints/ontologies; user models may be graphs — closer to a hand-drawn interest map than mined KG-rec embeddings.
• From 2026-08-21-autoresearch-best-architecture-for-a-rec-system-web-app: Official quota — 100 search.list/day; playlistItems.list / videos.list / channels.list cost 1 unit; watch history still watchHistoryNotAccessible.
• From 2026-08-21-autoresearch-best-architecture-for-a-rec-system-web-app: Developer Policies — no substitute YouTube app; no recreate browse without “significant independent value.”
• No fetched page designs, measures, or crowns a single best stack for this use case.

Evidence we need

• A cited reference architecture (or even a documented personal experiment) that composes a user-drawn interest graph with YouTube’s Data API under the substitute-browse rule and reports where ranking ran.
• A ranking of local-first vs Solid vs hosted PKB for this YouTube-first personal-scale case — not a general PKB survey.

How to resolve

Do not treat KGERA / K-RagRec / RecGPT-Mobile / Ink & Switch / Solid as interchangeable “the answer.” They are different layers (mined-KG serving, industrial implicit-feedback split, data-ownership invert). A later pass would still need a comparison that names the user-drawn graph and YouTube’s catalog constraints in one architecture. Do not invent a Data Portability finding. Leave can-a-user-owned-interest-graph-produce-better-recs open.

Related

• Queue entry: interest-graph-recs-web-architecture
• can-a-user-owned-interest-graph-produce-better-recs
• local-first-software
• on-device-recommender
• multi-stage-rec-serving
• knowledge-based-recommender
• youtube-data-access-constraints
• user-owned-graph-to-quota-aware-youtube-serving