MindZJ: The AI-Native, CLI-First Note-Taking App That's Everything Obsidian Wasn't

By Prahlad Menon 3 min read

The Obsidian model has been the default for serious note-takers for five years: local markdown files, a plugin ecosystem, a graph view. It’s good. But it was designed before local AI was viable, it runs on Electron (~150MB), and its plugin security model is an afterthought.

MindZJ is what that design looks like when rebuilt from scratch with AI as a core assumption, not an add-on.

10MB installer. Rust kernel. Ollama wired in at the architecture level. Full CLI. Plugin sandbox with declarative permissions. Snapshots on every edit. Pure .md files that will open in any text editor forever.

The Architecture Difference

The foundational choice: Tauri instead of Electron.

Electron bundles a full Chromium browser and Node.js runtime into every app. That’s why Obsidian (and VS Code, and Slack, and Discord) are 100–200MB installers. The runtime overhead is inherent to the architecture.

Tauri uses the OS’s native WebView for UI and compiles the backend to native Rust. The result is functionally equivalent — web-based UI, full system access — but the installer is ~10MB and the runtime memory footprint is a fraction of Electron.

For a note-taking app that runs continuously in the background, this matters. MindZJ doesn’t eat 400MB of RAM just idling.

AI Built Into the Kernel

The key design decision: AI backends are first-class citizens in MindZJ’s Rust kernel, not plugins or API wrappers.

MindZJ Rust Kernel
├── AI backends (first-class)
│   ├── Ollama (offline, any local model)
│   ├── Claude (Anthropic API)
│   └── OpenAI (GPT-4o, etc.)
├── Vault manager (plain .md files)
├── CLI engine
├── Plugin sandbox (WebWorkers + declarative permissions)
└── Mindmap renderer

In Obsidian, AI is a plugin. Plugins in Obsidian run with full Electron context access — they can read files, make network requests, and access system APIs without explicit permission grants. The security model is “trust the plugin developer.”

In MindZJ, plugins run in WebWorkers with declarative permissions. A plugin declares what it needs (filesystem read, AI access, network), the sandbox enforces it, and nothing beyond the declared scope is accessible. This is architecturally similar to how browser extensions work with the Manifest V3 permissions model.

The CLI Is the Point

Most note-taking apps are GUIs with optional CLI access bolted on. MindZJ treats the CLI as a first-class interface.

The CLI supports Unix pipes, making MindZJ scriptable:

# Summarize all notes modified today
ls -t ~/vault/*.md | head -10 | xargs mindzj summarize --model ollama/llama3.2

# Ask a question across your entire vault
mindzj query "What did I write about containerization?" --vault ~/vault

# Create a note from stdin
echo "Meeting notes: discussed Q2 roadmap" | mindzj create --title "Q2 meeting"

# Export mindmap for a note
mindzj mindmap ~/vault/project-plan.md --format svg

For AI agent workflows — where the agent needs to read and write to a knowledge base programmatically — this is the gap between “note app” and “agent memory store.” MindZJ’s CLI makes the vault accessible to any script, agent, or automation pipeline.

The soul.py Connection

This is directly relevant to our previous writing on AI agent memory.

soul.py (arXiv:2604.09588) stores agent identity and memory in plain markdown files — SOUL.md and MEMORY.md. The architecture is deliberately file-based so memory survives model switches, platform updates, and architectural changes.

MindZJ is, effectively, a native UI for these files:

  • View and edit MEMORY.md with live preview and AI assistance
  • Query your agent’s memory across sessions via the CLI or Ollama integration
  • Use the mindmap view to visualize knowledge connections
  • Add new memories via MindZJ and have them immediately available to soul.py’s RAG layer

The update grief problem documented in the MIT/Harvard AI companionship study — companions losing continuity when platforms update — is the exact problem soul.py + MindZJ solves. Your agent’s memory lives in files on your disk, editable by you, independent of any platform. MindZJ makes those files human-readable and manageable.

Mindmaps, Math, and Mermaid

MindZJ’s built-in capabilities beyond standard markdown:

Native mindmaps — not via a plugin, not via Mermaid, but a native mindmap renderer that converts note structure to visual graph. For project planning and knowledge mapping, this replaces the separate mindmap tool most workflows require.

KaTeX math — inline and block LaTeX, rendered live. For research notes, equations work the same way they do in Jupyter.

Mermaid diagrams — flowcharts, sequence diagrams, ER diagrams in code fences.

Three editor modes — live preview (rendered markdown), source (raw markdown), reading (distraction-free), toggled with Ctrl+E. This is Obsidian’s model but native, not a plugin.

The Privacy Architecture

Nothing about MindZJ’s architecture requires network access:

  • Notes: plain .md on your disk
  • AI: Ollama running locally (Claude/OpenAI are optional, both off by default)
  • Plugins: sandboxed, declare permissions explicitly
  • Sync: not built in — use git, Syncthing, or rsync yourself

The “no cloud” position is architectural, not a policy promise. There’s no server to send your data to.

This is the meaningful difference from Notion, Roam, or any SaaS note-taking tool. Privacy-by-architecture vs privacy-by-policy. One is enforceable; the other requires trusting the company.

How to Install

# Download from GitHub releases (~10MB)
# github.com/zjok/mindzj/releases

# Or build from source (requires Rust + Node.js)
git clone https://github.com/zjok/mindzj.git
cd mindzj
npm install
npm run tauri build

Cross-platform: Windows, macOS, Linux. iOS and Android builds from the same codebase.

Resources

Related reading: