-
Notifications
You must be signed in to change notification settings - Fork 0
rationale
Three decisions that shape everything else:
concepts/pages are markdown files. You can git clone your wiki. You can grep it. You can edit it in vim while the server is running and it'll re-index on the next read. The architecture/index-and-search is derived — deleting .mind-map.db and restarting reproduces it perfectly.
This is the opposite of comparisons/notion (database is source of truth, no files exposed) or comparisons/obsidian (files, but its database/cache state is opaque). It's the same posture as comparisons/logseq and Foam, but with first-class architecture/mcp-server.
The architecture/wiki-engine has one set of operations: Get, Create, Update, Delete, Move, Search, Backlinks. Both the architecture/http-api (humans via architecture/web-ui) and the architecture/mcp-server (agents) are 5-10 line adapters over those methods.
No agent-specific data path means no parity bugs. An agent and a human can stare at the same page at the same time. The agent's get_page and the human's URL render the same body, same concepts/backlinks, same concepts/frontmatter.
mind-map is a 38 MB static Go binary. No CGO. No Node runtime. No separate index daemon. No Electron. See design/lightweight for the numbers.
Why does this matter? Because the alternative (comparisons/notion / comparisons/obsidian / comparisons/logseq) costs hundreds of MB of disk and RAM per running wiki, and adds an operational dependency on someone else's runtime. A static binary you can put on a USB stick is a different category of software.
- No real-time collaboration. That requires a sync layer we deliberately don't include.
- No native mobile. A web UI in mobile Safari is the answer; native apps would imply a different architecture.
-
No proprietary file format. Worst case, you have a tree of
.mdfiles. Best case, you have a queryable graph.
- introduction — for the user-facing version
- comparisons/index — head-to-head with alternatives