Autoresearch: user-owned interest graph for healthier YouTube recs

Generated by /autoresearch on 2026-08-21. Synthesized across 3 rounds from 14 web pages, anchored by Grokipedia Knowledge_graph. 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. No spark is cited.

Summary

A user-owned interest graph is a plausible rec-control object: knowledge graphs are already used to power recommendations, property-graph engines (Neo4j Community among them) exist at personal/DIY scale, and two fetched academic papers show that user-side graphs or explicit controls can reduce over-personalization in lab settings. None of those papers tests the claim against YouTube’s live homepage or Up Next feed.

YouTube’s own documentation says recommendations — not search or subscriptions — drive a significant share of viewership, and that the homepage is primarily watch-history-based while Up Next is primarily “what you are watching now.” Mozilla’s crowdsourced YouTube Regrets study says most regretted videos arrived via recommendations, not search. Those two pictures do not agree on whether the feed stays “centered.”

The binding constraint is access, not graph-database choice. The YouTube Data API returns watchHistoryNotAccessible for watch history, default search is capped at 100 search.list calls per day, and the Developer Policies forbid using the API as a substitute for YouTube Applications or recreating the browse experience without “significant independent value.” Google Takeout can export a user’s Google data (including YouTube) as a delayed archive, not as a live rec API.

Findings

What a knowledge graph is, and why it is the natural store

A knowledge graph represents entities as nodes and typed relationships as directed edges, often with properties or provenance on either. Grokipedia’s primer distinguishes this from a plain graph store: a knowledge graph adds semantics (ontologies, typed relations) so the graph can be queried and reasoned over, not just traversed (Grokipedia, Knowledge graph). Two implementation families are named there: RDF (triples; SPARQL; OWL/SHACL when you want inference and validation) and property graphs (nodes and edges with key-value properties; Cypher). Both are used for recommendation systems in that primer; Google’s 2012 Knowledge Graph is the industry popularizer, not a personal-app template (Grokipedia, Knowledge graph).

Neo4j’s own getting-started docs describe the property-graph model in operational terms: labeled nodes, typed directed relationships, properties on both, schema-optional (indexes and constraints when you want them), traversals as the query style (Neo4j graph database concepts). That shape matches an interest graph one would draw: Person/Topic/Creator/Video nodes and CARES_ABOUT / RELATED_TO / WATCHED edges, with optional weights or timestamps as properties.

Graph-database tradeoffs at personal scale

Fetched official docs support a few comparisons. They do not include independent benchmark numbers, list prices, or a bake-off of Kuzu / SQLite / FalkorDB — those appeared in search results and were not fetched.

Property graph vs RDF. Grokipedia frames RDF as the Semantic Web / interoperability path (URIs, SPARQL, OWL inference, SHACL validation) and property graphs as the application-traversal path (labels, properties on edges, Cypher) (Grokipedia, Knowledge graph). Neo4j documents only the property-graph side and treats schema as optional — useful if the user’s graph is meant to grow by hand rather than by ontology committee (Neo4j graph database concepts).

Community vs server/cluster. Neo4j’s operations manual (product version 2026.07 on the fetched page) says Community Edition is a fully functional single-instance engine: ACID transactions, Cypher, programming APIs, “ideal for learning Neo4j, do-it-yourself projects, and applications in small workgroups.” Enterprise adds clustering, online backup, RBAC, multiple user databases, and related production features. Community is GPLv3; Aura is the hosted latest-server option (Neo4j Operations Manual, Introduction). For a single-user interest graph, the official text itself points at Community / DIY, not a cluster.

Operational cost that is documented. Community still implies a running Neo4j process (or an embedded JVM, which this pass did not fetch in full). Enterprise features the manual lists — online backup, clustering, LDAP — are not needed for a personal graph and are not in Community (Neo4j Operations Manual, Introduction). Cypher is now versioned separately from the server (Cypher 5 frozen as of Neo4j 2025.06; Cypher 25 receives new language features); that is a longevity/compat note, not a rec-quality claim (Neo4j Operations Manual, Introduction).

What this pass did not settle. Embedded engines, SQLite recursive-CTE graphs, RDF stores (Jena, GraphDB, Stardog), and Postgres graph extensions were not fetched as official docs. Do not treat any of them as compared here.

How YouTube’s feed actually ranks

YouTube’s 15 September 2021 engineering post (Cristos Goodrow) is the longest official description fetched. Recommendations appear on the homepage and in Up Next. They “drive a significant amount of the overall viewership on YouTube, even more than channel subscriptions or search.” The system does not use the viewer’s social network; it predicts videos the viewer wants to watch by comparing viewing habits to similar viewers. It “learn[s] every day from over 80 billion pieces of information” called signals: clicks, watchtime, survey responses (“valued watchtime” = 4–5 star survey ratings), sharing, likes, and dislikes. Watchtime was added in 2012 after clicks proved cheap to farm; that change produced “an immediate 20% drop in views,” which the post treats as acceptable. The system is not a fixed recipe (YouTube Blog, On YouTube’s recommendation system).

Creator-facing Help copy matches the signal list and adds subscriptions, “Not interested,” and “Don’t recommend channel.” Feature split: Up Next uses the video currently playing as the main signal; homepage primarily uses watch history. Turning watch history off (with no significant prior history) leaves the homepage as search bar + guide, not a personalized grid (YouTube Help, How YouTube works for you).

Google Research’s 2016 RecSys paper (Covington, Adams) is the technical ancestor still cited for architecture: a two-stage information-retrieval split — deep candidate generation, then a separate deep ranking model — at YouTube scale. Only the abstract was fetched; do not invent layer sizes or features from memory (Google Research, Deep Neural Networks for YouTube Recommendations).

YouTube’s own answer to the rabbit-hole question. Goodrow writes that a “growing number of independent researchers” conclude recommendations are not steering viewers toward extreme content, and that news/political consumption “more generally reflects personal preferences.” The company demotes “borderline” content; it reports a 70% drop in U.S. watchtime on non-subscribed recommended borderline content after 2019 demotion, and says consumption of recommended borderline content is “significantly below 1%,” with a goal of below 0.5% of overall views. Demoting “salacious or tabloid-type content” was associated with a 0.5% increase in watchtime over 2.5 months. The post also says personalized diversity (mixing the current topic with other history-based topics) is intentional (YouTube Blog, On YouTube’s recommendation system).

Mozilla’s contrary picture. Mozilla’s YouTube Regrets project (RegretsReporter; 37,380 volunteers; 3,362 reports from 1,662 volunteers in 91 countries, July 2020–May 2021) frames recommendations as the source of most regretted watches: 71% of regret reports were recommended videos, and recommended videos were 40% more likely to be regretted than searched-for videos. Mozilla also reports a 60% higher regret rate in countries where English is not the primary language (17.5 vs 11.0 regrets per 10,000 videos watched; 95% CIs given on the page). The report is crowdsourced and self-defined (“regret” is not a YouTube policy class); Mozilla says that is intentional. It asks YouTube to give people “meaningful control over how their data is used for recommendations, including allowing people to opt-out of personalized recommendations” (Mozilla, YouTube Regrets).

These two sources are not measuring the same thing. YouTube reports classifier-demoted “borderline” watchtime. Mozilla reports user-flagged regret, including off-topic, body-image, conspiracy, and policy-violating videos. A user-owned interest graph would be aimed at Mozilla-style off-intent drift (and at ordinary entertainment rabbit holes), not only at YouTube’s “borderline” bucket.

Can a user-owned graph produce better, more centered recs?

What the fetched papers actually show.

Wang, Feng, Nie, and Chua (SIGIR 2022) define a User-Controllable Recommender System (UCRS): alert the user if they are in a filter bubble, accept four kinds of control commands (fine-grained “more of feature X” and coarse “no bubble w.r.t. this feature”), and adjust on the fly via counterfactual inference that blocks stale user representations. They argue passive like/dislike feedback is too slow to break a bubble, and that accuracy-vs-diversity tradeoffs in prior work hurt fidelity. Experiments on three datasets (DIGIX-Video, Amazon-Book, ML-1M — not YouTube’s production feed) are described as maintaining accuracy while following user controls (arXiv abs 2204.13844).

Spadea and Seneviratne (ISWC 2025 companion) treat a Personalized Knowledge Graph (PKG) as an editable user-side preference graph. They detect over-personalization as a feature-pair bias (a “PIE”), then symbolically adapt the PKG (soft reweight, hard invert, or remove biased triples) before prompting an LLM. On a Food.com recipe benchmark, personalized soft adaptation raised Out-PIE recommendations from 0.2517 (no adaptation) to 0.3237 and slightly lowered invalid recommendations (0.4901 → 0.4604). Prompt-only “please avoid the bubble” instructions did worse than doing nothing (Out-PIE 0.1925, Invalid 0.6211). The dataset is recipes, not YouTube (arXiv html 2509.07133).

What that does and does not license. Both papers support the mechanism Paul is asking about: an explicit, user-owned graph (or user command that edits the user representation) can steer recs off an engagement-inferred loop without a full model retrain. Neither paper compares a user-built interest graph to YouTube’s live homepage or Up Next. Neither measures “healthier” in the Mozilla-regret sense. “Better, more centered than YouTube’s feed” is therefore untested in the fetched record. The honest status of can-a-user-owned-interest-graph-produce-better-recs after this pass: narrowed, not resolved.

A second caution from the PKG paper itself: if the graph is inferred from the same watch history YouTube already uses, it can become another PIE and needs explicit adaptation. A graph the user draws is a different object — closer to UCRS’s control commands than to a mined PKG — but the fetched papers do not test a hand-built graph.

Practical constraints: YouTube data, graph shape, rec approaches

Watch history is not in the Data API. playlistItems.list documents forbidden (403) watchHistoryNotAccessible: “Watch history data cannot be retrieved through the API.” Watch Later is likewise watchLaterNotAccessible (PlaylistItems: list). That closes the obvious “OAuth the user and read HL” design.

What the API still gives. Public metadata is cheap: videos.list, channels.list, playlistItems.list (user uploads / ordinary playlists), and subscriptions.list cost 1 unit each (Quota Calculator). Keyword/topic candidate generation is not: search.list lives in its own daily bucket with a default of 100 calls per day, 1 unit per call; each extra results page is another call (Search: list; Quota Calculator; Quota and Compliance Audits). Default allocation for everything else is 10,000 units/day; extra quota requires a compliance audit (Quota and Compliance Audits). A neighborhood-of-the-graph rec loop that issues a search.list per interest node will exhaust the search bucket in one sitting.

Takeout is a batch export, not a rec API. Google Account Help documents Takeout as an archive: pick products, create an export, wait minutes-to-days, download a link that expires in about 7 days (5 downloads). YouTube is a listed product; a documented custom Takeout URL includes youtube among product ids. Time-range export is not supported. Google also points developers at the Data Portability API for third-party apps (How to download your Google data). This pass did not fetch the Data Portability API’s YouTube-history scope list, so do not claim a live watch-history API exists there.

Policy wall around a competing feed. Developer Policies § (fetched page, software-development / general policies): API Clients “must not … use YouTube API Services to create, offer, or act as a substitute for, or substantially similar service to, any YouTube Applications.” They “must not mimic or replicate YouTube’s core user experiences by recreating features or process flows unless they add significant independent value.” Example given: do not recreate the browse experience without that independent value. Also: do not retrieve API Data by any technology other than YouTube API Services; do not replace API Data with independently calculated stand-ins; stored Authorized Data must be deleted within 7 days of in-app revocation and within 30 days of Google-settings revocation (YouTube API Services — Developer Policies). A personal “my interest graph, then a YouTube-like homepage” is exactly the fact pattern that paragraph is written for. A research tool that filters a user’s own Takeout archive against a graph they drew is a different fact pattern; this pass did not fetch a YouTube ruling on that.

Graph shape implied by the sources (not a schema to implement). From Neo4j’s model plus the rec papers: nodes = user-declared interests / entities; edges = user-drawn relations (typed, optional weight/decay as properties); optional WATCHED / SUBSCRIBED edges only if the user imports Takeout or subscriptions via the API. Rec approaches the papers actually describe: (1) neighborhood / feature-control re-ranking (UCRS), (2) symbolic edit of the user graph then generate/rank (PKG adaptation), (3) YouTube-style two-stage retrieve-then-rank (Covington abstract) — the last is what a 100-search/day cap makes expensive. None of the fetched sources specifies a decay function or a required ontology.

Contradictions and open questions

• YouTube vs Mozilla on whether the feed pulls people off-intent. YouTube: recommended borderline watchtime is a small, falling share and independent papers (unnamed in the fetched post) say recommendations do not steer toward extremes (YouTube Blog). Mozilla: 71% of regretted videos were recommended; recommended videos 40% more likely to be regretted (Mozilla). Different metrics; both fetched; neither adjudicated here.
• “Better, more centered than YouTube” is untested. UCRS and PKG papers support user-side control in other domains (arXiv 2204.13844, arXiv 2509.07133). No fetched study runs a user-drawn interest graph against YouTube’s live feed.
• Watch-history path. API: closed (playlistItems.list). Takeout: archive only (Google Account Help). Data Portability API: mentioned, not fetched.
• Embedded / RDF / SQLite graph engines. Not fetched. Neo4j Community is the only engine with official docs in this pass.
• Whether a graph-gated YouTube client is a “substitute service.” The policy text is fetched and relevant (Developer Policies); no fetched enforcement example.

Provenance

Rounds run: 3 of 3

Sub-questions by round:

Round 1 (broad survey):

1. What graph-database options and tradeoffs apply to a personal knowledge graph that might later feed recommendations?
2. How does YouTube describe its own recommendation system, and what does it claim about rabbit holes?
3. What official YouTube data-access paths exist (Data API, Takeout, quotas, ToS)?
4. Does recsys literature support user-owned / explicit interest graphs as more centered than engagement feeds?

Round 2 (drill-down):

1. Independent evidence on YouTube rabbit holes / regretted recommendations — targeting the gap between YouTube’s official claim and user reports.
2. Official graph-DB docs for property-graph vs operational editions — targeting the lack of primary-source DB comparison in round 1.
3. Academic HTML on user-controllable recs and personalized knowledge graphs — targeting the rec-quality claim.
4. Developer Policies language on substitute/browse clients — targeting the legal constraint around a third-party feed.

Round 3 (resolve remaining uncertainty):

1. Exact search.list quota (candidate-generation bottleneck).
2. Neo4j property-graph primitives (graph shape for an interest graph).
3. Official Takeout mechanics (the remaining watch-history path).

Anchor source (Grokipedia, fetched before round 1):

• Knowledge graph — 25,017 chars extracted via grokipedia-fetch — RDF vs property graphs, recommendation as a named application, not a YouTube-specific page. No Grokipedia page exists for “user-owned interest graph” or “YouTube recommendation algorithm” as a lead slug.

X sources: skipped (--include-x not passed).

URLs fetched (14 successful, 0 failed):

Round 1:

• On YouTube’s recommendation system — official / 15 Sep 2021 — signals, homepage vs Up Next, borderline-demotion claims.
• Learn more about how YouTube works for you — official Help — watch-history homepage, current-video Up Next, user controls.
• Quota and Compliance Audits — official — 100 search.list / 100 videos.insert / 10,000 other units; audit for more.
• PlaylistItems: list — official — watchHistoryNotAccessible / watchLaterNotAccessible.
• Deep Neural Networks for YouTube Recommendations — Google Research abstract — two-stage candidate generation + ranking (2016).

Round 2:

• YouTube API Services — Developer Policies — official — no substitute/substantially similar YouTube Application; no browse replica without independent value; Authorized Data deletion windows.
• YouTube Regrets — Mozilla Foundation — 71% / 40% / 60% regret figures; asks for user control and opt-out.
• Neo4j Operations Manual, Introduction — official — Community vs Enterprise; CE for DIY / small workgroups; current docs version 2026.07.
• User-controllable Recommendation Against Filter Bubbles — academic (SIGIR 2022 abs + HTML body as served) — UCRS / UCI; not YouTube production.
• Avoiding Over-Personalization with Rule-Guided Knowledge Graph Adaptation — academic (ISWC 2025 companion HTML) — PKG adaptation; Food.com numbers only.

Round 3:

• How to download your Google data — official Takeout — archive delay, ~7-day expiry, no time-range export, Data Portability API mentioned.
• Graph database concepts — official — nodes, typed directed relationships, properties, optional schema.
• Search: list — official — 100 calls/day search bucket, 1 unit/call.
• Quota Calculator — official — method costs; search and insert in separate buckets.

Not fetched (search hits only; do not cite as evidence): vendor/blog graph-DB bake-offs (DEV, youngju.dev, knodegraph), Medium rabbit-hole essays, Stack Overflow / GitHub Takeout walkthroughs, the Covington PDF body, Data Portability API reference, Kuzu / SQLite / RDF-store official docs.

Tools used: WebSearch, WebFetch, grokipedia-fetch (skill). No x-fetch. Generated: 2026-08-21 12:40 UTC