September 7, 2026Blog

Survey: turning notion-test into a "second brain"

Date: 2026-09-05
Status: feasibility report, NOT yet a spec. Waiting for project owner to choose a direction.
Approach: three parallel survey branches (concepts + hot repos, implementation approach

technical, current repo status), star counts queried directly from GitHub API on 05/09/2026.

1. What is a second brain

"Second brain" is a working method for users, not a type of software. Software only needs enough features so users can apply the method.

Method	Core idea	Corresponding software features
CODE (Tiago Forte)	Capture → Organize → Distill → Express: capture everything, organize by usefulness, gradually distill, reuse to create new work	Fast capture (clipper, share), progressive highlighting/summarizing, templates
PARA	Put notes into 4 buckets: Projects, Areas, Resources, Archives	Page-level folders/tags, filtered views
Zettelkasten	One idea per note, must link to other notes, MOC (table of contents for topics) emerges from links	Wikilink, backlink, graph view

The origin of all current "backlink + graph" features is Zettelkasten. The AI layer (semantic search, chat with notes, link suggestions) is just an additional overlay.

2. Repos attracting attention 2025–2026

Repo	Stars	Takeaways
AppFlowy	76k	Notion alternative, local-first, AI as optional plugin
AnythingLLM	66k	Chat with documents, plug in multiple LLMs + vector DB
mem0	65k	Memory layer for agents, not a note-taking app
Logseq	45k	Outliner, block reference, default daily notes, graph
Quivr	39k	Used to be "second brain", now pivoted to enterprise RAG
Khoj	37k	Personal assistant: chat over notes + web, scheduled agents
Reor	8.6k	100% local AI notes: auto-linking, Q&A, semantic search (LanceDB)
obsidian-copilot	7.7k	Plugin to chat with vault, has lexical mode that doesn't need indexing
obsidian-smart-connections	5.4k	"Related notes" via local embedding, zero setup
obsidian-second-brain (eugeniughelbur)	4.3k	45 commands for Claude Code to operate on vault, scheduled maintenance agent
obsidian-claude-code-mcp (iansinnott)	348	MCP server for Claude Code to read/write the currently open vault

Warning: AgriciDaniel/claude-obsidian (14.6k stars) and tinyhumansai/openhuman (39k stars) show signs of star inflation (fork/star ratio exactly 10.0%, homepage selling courses, 64 followers). Only use them to reference the "LLM Wiki" idea (Karpathy, 04/2026), do not treat star counts as evidence.

Common features, ordered by frequency

Plain Markdown, local-first
Wikilink + backlink + graph view
Semantic search via embeddings
Chat with all notes (RAG)
Daily notes / block reference
Tags
AI link suggestions / related notes
Scheduled agents that auto-maintain the vault
Templates
Metadata queries (Dataview)
Web capture
Encryption / P2P

The clearest 2026 trend: agentic second brain. Claude Code or MCP read/write the note vault directly, agents run in the background to link, summarize, and clean up.

3. Where notion-test stands

Second brain feature	Current status	Anchor points
Wikilink	ALREADY HAS one-way: inline `@page` stores `pageId`, name is read dynamically, deleting page greys out link	`src/blocknote/schema.ts:255`, `Editor.tsx:583` (trigger `@`)
Backlink	Not present. No index of "which pages point to this page"	Wire format `pageLink` + `pageId` already has test keys (`src/pageLinkWireFormat.test.ts`)
Graph view	Not present	Built on top of backlink index
Tags	Not present. Only has `categoryId` (one group per page)	`Page` in `src/models/types.ts`, `upsertPageMeta` template field-by-field
Full-text search	Present, in-memory, opens Y.Doc for every page on each Ctrl+K	`SearchModal.tsx`, `searchPages.ts`
Semantic search / embedding	Not present	Server already has Postgres, Node, LLM proxy
In-editor AI	ALREADY HAS: `/api/ai/stream` SSE, three modes (generate/edit/compress), Anthropic + OpenAI	`server/src/aiApi.ts`, `src/ai/`
External read/write agent	ALREADY HAS REST API agent: create, read/write markdown, find titles, edit meta	`server/src/agentApi.ts`, `notion-agent-api` skill
Background jobs	ALREADY HAS `agent_tasks` queue for Flywheel polling	`server/src/db.ts:245`
Daily notes / capture	No UI yet, but agent API for creating pages is sufficient
Local-first	ALREADY HAS: Y.Doc + IndexedDB, optional sync

Conclusion: notion-test already has a better agentic foundation than most repos in section 2, but lacks exactly the method layer (backlink, tags, graph) required by Zettelkasten/PARA. This is the cheapest and most worthwhile part to do first.

Gaps discovered when reviewing code

pageLink is not in LOAI_MAT_MAT (src/agent/matMatMarkdown.ts:25) and markdownExport.ts has no branch handling it. Very likely @page silently disappears when the agent reads a page via API, and a GET → PUT roundtrip will delete the link. This hasn't been measured with tests yet and must be verified before any batch of work, because if the agent can't see backlinks then the "agentic second brain" is broken at the root.

4. Three implementation directions

Direction A: Zettelkasten foundation (backlink, tags, graph)

Backlink index computed on the server when Hocuspocus persists the doc: scan

Y.XmlFragment for pageLink nodes, write table page_links(from_id, to_id). Client calls GET /api/pages/:id/backlinks. Reason for server-side: multiple machines see the same results, public /p/ pages can also use it without needing the workspace doc.

"Mentioned in" panel at the bottom of the page, including the paragraph containing the link.
Tags: tags: string[] field on Page, write each field following the

upsertPageMeta pattern, tag filter tab reuses the category pattern.

Graph view: react-force-graph (sufficient for a few hundred to a few thousand pages), color using the existing gold token.
Fix markdown loss: export @page as [[Page name|pageId]] or equivalent syntax that preserves pageId and can be imported back.
Complexity: Medium. Does not touch the public bundle except for the backlink panel for /p/.

Embeddings on the server via API (OpenAI text-embedding-3-small or Voyage multilingual), stored in Postgres pgvector. Do not run models in the browser: good Vietnamese models (bge-m3, multilingual-e5) are hundreds of MB, small models that can run in-browser are mainly English, Vietnamese quality unmeasured.
Chunk by block, reuse the already validated markdown converter, embed on the Hocuspocus persist cadence (debounced), not per keystroke.
Three UIs on the same index: semantic search in Ctrl+K, "Related pages" panel next to the editor, "Ask the note vault" reusing /api/ai/stream with a retrieve step before the prompt.
Complexity: Medium. Risks: embedding cost, VPS needs pgvector extension installed, prompt must separate chunks from system instructions (lesson from spec 3).

Direction C: Agentic second brain (MCP, capture, maintenance agents)

Thin Node MCP server wrapping the existing agent API: list_pages, search_pages, read_page, write_page, append_page, get_backlinks. Claude Code on PC uses this directly instead of curl.
Fast capture: bookmarklet or PWA share_target calling the agent API directly to create pages in the "Inbox" group. Daily note: button to create a date-based page.
Scheduled maintenance agents via agent_tasks + Flywheel: suggest links for new pages, weekly summaries, tag suggestions. Results are written as proposals for user review, not auto-editing content.
Complexity: Low for MCP and capture, Medium for maintenance agents.

Recommended order

A → B → C. A is the foundation needed by both B and C (backlinks for graph, for MCP to return get_backlinks, for agents to suggest links). B delivers the clearest "smart second brain" feel but needs A to display correctly. C is cheap and fits your current workflow (Claude Code + Flywheel), so a thin MCP can be slotted in right after A.

Each direction is a separate spec following the docs/superpowers/specs/ convention.

5. Repo-specific constraints and risks

Public bundle: nothing on /p/ may import collab/sync/persistence, 2000-byte gzip cap for the entry. Public backlink panel must receive data via API, not via workspace doc.
CRDT: server indexes are computed from Y.Doc updates, not by writing directly to the documents table. All indexes are derived and can be rebuilt from the doc.
Lossy Markdown: lesson from PR #74. Any new syntax ([[...]], tags) must round-trip through matMatMarkdown or be included in the lossy list.
Protected paths: adding dependencies (react-force-graph, pgvector) touches package.json, PR needs harness-approved label.
Server has no typecheck in verify, manual deploy via install-vps.sh.
Two auth mechanisms: MCP and capture use API keys, not SSO cookies.

6. Questions for the project owner

How do you use notion-test more often: typing and manually linking

(Zettelkasten, prioritize A) or dumping ideas in and letting AI/agents organize them (prioritize B + C)?

Are you okay with sending note content to an external embedding API? If not, direction B must run a model on the VPS, RAM needs to be measured.
Do backlinks and graph need to appear on public /p/ pages, or only inside the app?
Scale: roughly how many pages do you have now, and what is the expected number in a year? This affects the choice of graph library and search indexing approach.
Do you want to immediately verify the @page markdown-loss issue as a separate bugfix PR before discussing the spec?