Why local-first matters for your notes (and why your AI should still be able to read them)
*May 13, 2026 · 10 min read*
"Local-first" became a load-bearing phrase in note-taking around 2020 — the moment people realized Evernote could revoke their data, that Roam Research could disappear overnight, that they had ten years of writing trapped in someone else's database. The response was a shift toward plain-text, file-on-disk note tools: Obsidian, Logseq, Bear, iA Writer. The core promise of local-first: your notes are *files you own*, not records in someone else's table.
The promise is real and it's still right. But the strict interpretation — files on disk, no cloud — collides with a separate good idea: your AI should be able to read your notes from any modern client. You can't do that if the notes only live on your laptop. The honest answer in 2026 is local-first storage with a managed cloud index, which is what MindWiki ships.
This article walks through what local-first actually means, what people give up when they go strict-local, what the right architecture looks like, and how MindWiki implements it.
TL;DR
Local-first doesn't mean "no cloud." It means "you own the canonical files, locally, and you can leave any time." A managed cloud index that mirrors those files isn't a betrayal of local-first — it's how you let AI clients query your data without making your laptop the single point of failure. MindWiki stores the canonical vault as plain markdown on your Mac, syncs it through a managed cloud, and lets every modern AI client read it via MCP. You can export the whole vault as a zip at any time and walk away.
What "local-first" was supposed to mean
The local-first principles that came out of Ink & Switch and similar groups in the late 2010s laid out seven requirements. The two most important for note-taking:
- No spinners. Your work loads instantly. You're never blocked on the network.
- Long-term data ownership. The format is open, the files are on your disk, and the tool can disappear without you losing access.
Notice neither principle forbids a cloud. They forbid the cloud being the *only* place your data lives. A managed cloud mirror that you can throw away without losing the underlying files is perfectly compatible with local-first.
The strict-local interpretation and what it costs
Some products and some users adopt a stricter reading: no cloud, no managed services, no external indexes. Pure local.
That stance has costs in 2026:
1. No web access
The hardest cost. You can't open your vault from a borrowed laptop, a phone browser, or a public machine when you don't have your usual device. Obsidian Mobile exists but it's a worse editor than the desktop app. Most people who go strict-local end up emailing themselves notes from other devices, defeating the purpose.
2. No AI bridge
Modern AI clients — Claude.ai, ChatGPT, Codex — need to reach your data over a network. If your vault lives only on your laptop, the AI can't talk to it unless your laptop is also running a server, exposed somehow. Most people who try this give up and stop using AI on their notes.
3. Sync is your problem
Two devices need to see the same vault. Without a managed sync layer you're running iCloud Drive (slow, occasionally corrupts files), Syncthing (works, takes work to configure), or git (works, requires merge discipline). Each of these is a part-time job.
4. Backups are your problem
You're responsible for snapshots, versioning, off-site copies. People underestimate how much engineering went into the "your data is safe" guarantee of managed services until they have to provide it themselves.
The compromise that doesn't compromise
The right shape in 2026:
┌──────────────────────────────────────┐
│ Canonical vault │
│ (plain markdown on your Mac) │ ← you own this
└────────────────┬─────────────────────┘
│ bi-directional sync
▼
┌──────────────────────────────────────┐
│ Managed cloud mirror │ ← you can throw this away
│ (markdown copy + search index) │
└────────────────┬─────────────────────┘
│ queryable via MCP/REST
▼
┌──────────────────────────────────────┐
│ AI clients, web access, integrations│
└──────────────────────────────────────┘- The canonical vault is on your laptop. You can open it in Finder. You can grep it. You can put it in git. You can copy the folder to a USB drive and walk away with everything.
- The managed cloud mirror is a copy. If the cloud disappears tomorrow, you still have the canonical vault. The cloud's value is *queryability* (search, embeddings, graph, AI access) — not storage.
- AI clients and web read from the cloud mirror because that's where the queryable indexes live. They don't need access to your laptop.
This is local-first as it was meant to be read. Storage is yours. Convenience layers can be managed.
How MindWiki implements this
MindWiki is built around exactly the architecture above:
Your vault is plain markdown on your Mac
The macOS app stores your vault as a folder of .md files plus a _assets/ subfolder for binaries. You pick the folder. You can open it in Finder. The file names are slugs of the page titles. Frontmatter is YAML. Links are [[wikilink]] syntax. There is no proprietary database between you and your text.
Sync is bi-directional and live
Edits on the Mac appear in the web app within seconds. Edits in the web app appear on the Mac within seconds. Conflicts produce *.conflict-*.md files instead of silent overwrites — you can see exactly what happened and merge by hand if needed.
The managed cloud mirror is just files
The cloud doesn't have a proprietary block store. It has:
- A copy of every markdown page.
- A SQLite-style index of metadata.
- A managed embedding index, kept in sync with the markdown.
If you cancel your account, the canonical vault on your Mac is unaffected. You can export the entire vault as a zip at any time from Account → Settings. The format is the same one you write in.
AI clients read the cloud mirror
When Claude.ai or ChatGPT calls mindwiki_search, they're hitting the cloud index. Your laptop doesn't have to be on. The AI gets fast, queryable access; you get to close your laptop and go for a walk.
You can leave any time
This is the part of local-first that matters most: the exit. With MindWiki:
- Export the vault as a zip.
- Open it in Obsidian, iA Writer, VS Code — anything that reads markdown.
- Wikilinks transfer; frontmatter transfers; attachments transfer.
You're not locked in. The whole point of plain markdown is that the format is bigger than any one tool.
The cases where strict-local still wins
It would be dishonest to claim the compromise is right for everyone. Strict-local is the right answer when:
- Your notes are highly sensitive — legal, medical, classified. The managed cloud isn't appropriate even with encryption.
- You're committed to a single machine and never need web/AI access from elsewhere.
- You explicitly enjoy the maintenance of running your own sync + backups.
If any of those describe you, stay strict-local. Obsidian without Sync, Logseq without their cloud, or a custom git-backed setup is what you want.
For everyone else, the compromise wins because it preserves the local-first guarantee (your data on your disk) and adds the convenience layer (AI access, web vault, managed sync) without forcing a trade-off.
What good local-first feels like in 2026
The right setup behaves like this:
- You open your laptop and the vault is already there.
- You edit a page. It saves instantly. You close the laptop.
- You're at lunch, you open the MindWiki web app on your phone, you see the page you just edited.
- You ask Claude a question about something you wrote six months ago. Claude pulls the relevant pages and answers.
- Three years from now, you decide MindWiki isn't for you. You export, open the zip in another tool, keep working.
Every step assumes plain files you own. None of them require trusting the cloud with primary storage. That's the promise local-first was supposed to deliver, finally delivered in a way that doesn't make you choose between ownership and convenience.