Roadmap

Everything below is judged by one question: does it make the knowledge base better, or does it only make this program bigger? The notes are the product. A feature that adds state this server owns exclusively has to justify itself twice.

The three headings below mean different things. Committed is work that will happen. Under consideration is not a promise. Rejected is a decision, recorded so it does not have to be argued again.

v1 — done

Storage

Plain Markdown with Obsidian-compatible frontmatter, wikilinks, tags and checkboxes. One directory per vault, four starting layouts, atomic writes, structural path validation, a trash with a retention window.

Search

SQLite FTS5 with BM25 ranking and snippets, reconciled at start and kept live by a debounced fsnotify watcher, plus a regular-expression fallback for everything a tokeniser cannot see.

Safe editing

Content hashes, exact-string edits that refuse ambiguity, eight section-edit modes, dry_run on every mutating tool and defaulted to true on the two that touch a whole vault.

Versioning

One git repository per vault, one commit per write naming the tool and the path, optional push to a remote after every commit, and three tools over that history.

Identity

OAuth 2.1 with discovery, dynamic client registration, PKCE and an HTML login page. Tokens in memory only. Multiple users, each scoped to named vaults, each optionally read-only.

Operations

Environment-first configuration, an optional config file, validate and reindex subcommands, one metadata-only audit line per tool call, and a distroless non-root image.

Committed

Work that will happen, in roughly this order. Each is here because v1 left a deliberate hole for it.

Semantic search over the reserved embeddings table

The index schema already contains an embeddings table with nothing in it. That was not an accident: it means turning semantic search on later is a data migration rather than a schema one, and that nobody has to rebuild an index from scratch to get it.

The shape is settled even though the implementation is not. It will be opt-in and off by default, and it will support two sources:

Local. A small embedding model reached over a socket on the same host — Ollama or anything with a compatible endpoint. No notes leave the machine.
Hosted. An OpenAI-compatible embeddings endpoint, configured with a URL and a key.

The hosted option deserves a warning attached to it in the documentation and here. It would be the first outbound network request this server has ever made, and what it would send is the text of your notes. That is a genuine change to the threat model described on the security page, which is exactly why it must be a decision you make explicitly rather than a default you inherit. FTS5 stays the primary index either way; embeddings extend note_search and note_related, they do not replace them.

Per-directory access control

Today access is per vault: a user who may open a vault reads every note in it. That is the honest limit named on the security page, and it is the most requested thing this project does not do. Rules of the form "this user may read projects/** and write nothing else" would make a single shared vault safe to give to a narrower agent, and would remove the current advice to split a vault whenever the access needs differ.

It is committed because it is the only limit on the list that people are likely to hit in normal use. It comes after semantic search because it touches every tool rather than one subsystem, and because a rule engine that is subtly wrong is worse than no rule engine at all.

MCP resources and prompts

v1 implements tools and nothing else, which was the right place to stop. Two parts of the protocol clearly fit afterwards:

Resources. Notes as addressable resources, so a client can attach one to a conversation directly instead of asking a tool to read it. Cheaper, and it lets the client show the user what was attached.
Prompts. The operations that are always the same sequence — the weekly review over daily_range, the cleanup pass over vault_review, capture-and-file — expressed as named prompts rather than reinvented by every agent.

Vault instructions already travel with the vault. Prompts are the same idea, one level up.

Incremental git gc

A commit per write means a repository with a great many small commits. Nothing goes wrong for a long time, and then one day a vault with tens of thousands of loose objects makes every git operation slow, which makes note_history and note_restore slow. Running git gc from cron works but is a thing you have to know about.

The plan is unglamorous and therefore likely to be right: a bounded, incremental repack triggered by loose-object count, run in the background, never blocking a tool call, and skipped entirely while a push is in flight. Housekeeping that nobody has to be told about is the point.

Under consideration

None of these are promised. Each would be added only if it turns out to be needed in practice rather than merely reasonable on paper.

Idea	Why it might be worth it, and what stops it
Import from Notion and Evernote	The people most likely to want a knowledge base in plain files are the people who currently do not have one. Notion's Markdown export and Evernote's ENEX are both convertible, and both lose things — databases become tables, nested pages become directories, Evernote's HTML becomes approximate Markdown. The hesitation is not the conversion; it is that a lossy import runs once, produces thousands of files, and is judged by its worst note. It may belong in a separate tool that writes into a vault rather than in the server itself.
Scheduled review digests	A weekly summary of what changed, what went stale and which links broke — the output of `vault_review` and `daily_range`, produced without anyone asking. The problem is that the server would need a scheduler and a way to deliver the result, and delivery means an outbound request. Writing the digest into the vault as a note avoids that neatly and is the version most likely to happen, if any does.
Backlink maintenance on external edits	The watcher reindexes when a file changes underneath the server, but a note renamed in Obsidian leaves the links pointing at the old name, exactly as Obsidian would. Detecting a rename and offering to fix the links would be genuinely useful and is genuinely hard to do without guessing.
Per-vault tool subsets	An archive vault that offers only reading tools, independent of the user's own permissions. Small, plausible, and possibly redundant once per-directory rules exist.
Attachment extraction	Text out of PDFs and images so that attachments become searchable. It would mean either a large dependency or an outbound call, and both are expensive for a feature whose absence is a mild annoyance.
A second index for structured queries	Frontmatter fields as columns, so "every note with `status: draft` older than a month" is one query. Today that is `note_search` plus filtering by the agent, which works and costs context.
Conflict detection for concurrent editors	Content hashes catch the case the server can see. Two people editing the same note in two Obsidian instances is a synchronisation problem this server did not create and cannot solve, but it could at least notice and say so.

Deliberately rejected

A read-only browse UI

The suggestion is reasonable on its face: the server already has an index, a search engine and an HTTP listener, so a small web page that lists notes and renders one would be a couple of hundred lines. It has been rejected, and the reason is worth recording.

A browse UI would be the first component of this project whose value depends on the software running. Everything else here is a lens over files you can already read: Obsidian renders them, an editor opens them, grep searches them, a forge displays them if you push the git remote. A web UI does not add a way to read your notes — it adds a worse way, because it will always be behind the tools that exist for exactly this and that you probably already have open.

And the cost is real. Rendering notes in a browser means a templating layer, HTML sanitising for Markdown that can contain anything, session handling for a browser rather than an API client, CSRF, and a new class of vulnerability in a process that currently exposes one JSON endpoint and a login form. It would be the largest attack surface in the project, added to serve a use case that is already served.

If a knowledge base needs its own viewer, something has gone wrong with the format. The correct answer to "I want to read my notes in a browser" is to point a static site generator at the directory, or to push to a git remote and read them there.

A proprietary storage format

A database would make search faster and edits cheaper. It would also make the notes unreadable without this program, which is the one thing that must never be true.

Automatic organisation

Moving, retagging or merging notes without being asked. A knowledge base whose structure changes on its own is one you stop trusting, and trust is the whole asset.

A hosted service

Somebody else's server holding your private notes is the shape this project exists to argue against. It runs on your machine, or it does not run.

Open questions

Genuinely undecided. Opinions from people running this are more useful than more thinking about it.

Should a vault be able to disable tools in its instructions file? It would let a vault say "no automatic merging here" and have that travel with the directory. It also puts a security-relevant decision in a file an agent can write, which is exactly the wrong place for one.
How much should note_related change when embeddings arrive? Shared tags and co-citation give explainable results; embeddings give better ones you cannot explain. Blending them may produce the worst of both.
Is thirty days the right trash retention? Long enough to notice a deletion, long enough that a vault used heavily accumulates a fair amount of it.
Should note_write exist at all? It is the only tool that can replace a note wholesale, it already requires a hash, and every use of it could be a section edit. Removing it would be a strong statement and would occasionally be infuriating.

Contributing

Issues and pull requests are welcome at the repository. The most valuable report is a description of how a real vault behaved badly — an edit that lost something, a search that could not find an obvious note, a layout that did not fit how you work. Those are hard to invent and easy to fix once seen.

A pull request that adds a tool should say which failure mode the tool makes impossible. That is the standard the existing thirty-four were held to, and it is the reason there are thirty-four rather than four.