Why I built this

In late 2024 I had about four years of notes spread across Notion, Bear, a folder of random .txt files, and one very cursed Apple Note titled "misc." None of them talked to each other. Notion felt like renting storage space in someone else's server room. Bear was great until I wanted to reference a note from my work vault inside a personal one. The .txt folder was honest but had no structure at all.

I looked at Obsidian, which does exactly what I needed. The plugin ecosystem is huge, the graph view is satisfying, and the file format is portable. But it's an Electron app, and I spend most of my time in the terminal. Opening a separate GUI application to look up a note I wrote three months ago felt like reaching for a different room.

So I started writing a small Rust CLI over a weekend. That was November 2025. The first version did exactly two things: resolve [[links]] in a directory tree and report broken ones. I used it for about six weeks before adding anything else.

What Caspira is not

It's not a replacement for Obsidian. If you want a canvas, a graph you can drag around, or plugin support, Caspira won't help you. It's also not a sync tool — I use git for that, and I suspect you can figure out a setup that works for you too.

It's also not trying to be a personal knowledge management system in the Zettelkasten sense. I find that terminology more distracting than useful. It's a note tool. Notes are files. Files have links. Links form a graph. That's the whole model.

The name

Caspira comes from the Caspian Sea — specifically from a paper I was reading about the sea's unusual hydrology when I needed to name the repository. The Caspian is a closed basin: water flows in from rivers and evaporates, but nothing flows out to the ocean. I liked the analogy for a personal note vault. Things come in, get connected, stay. Nothing leaks out unless you deliberately export it.

The -ira ending is just because caspian was taken on crates.io.

On maintenance

I maintain Caspira in my spare time. Issues and PRs are welcome but I'm one person with a day job, so response times vary. If something is broken in a way that loses data, I'll prioritize it. For everything else: patches make the project much more likely to move forward than feature requests.

The project is MIT licensed. Use it, fork it, ship something with it.

— e.m., somewhere with good coffee