Read your own capture database

Everything Jot has ever captured lives in one file:

%APPDATA%\com.wrivio.jot\jot.db

It is an ordinary SQLite database. No wrapper, no encryption, no proprietary container. Anything that reads SQLite reads it, which means you can verify every claim on this site yourself rather than taking any of them on trust.

Opening it

The sqlite3 command-line tool is the shortest path and ships with recent Windows builds; otherwise it is a single executable download.

Work on a copy. Not because querying is dangerous, but because the application may have the file open and there is no reason to introduce a question:

copy "$env:APPDATA\com.wrivio.jot\jot.db" "$env:USERPROFILE\Desktop\jot-copy.db"
sqlite3 "$env:USERPROFILE\Desktop\jot-copy.db"

Or point any graphical SQLite browser at that copy.

Looking around

.tables
.schema captures

The interesting table is captures. Every capture is a row, and the columns are readable without a decoder ring: the raw text exactly as you typed it, the parsed title, due and reminder times, tags, destination, whether it is a note or a todo, its status, and which application had focus when you pressed the hotkey.

A few queries worth having:

-- The last twenty things you captured.
SELECT datetime(created_at/1000,'unixepoch','localtime') AS when_,
       kind, title
FROM captures
ORDER BY created_at DESC
LIMIT 20;

-- Everything still outstanding, soonest first.
SELECT datetime(due_at/1000,'unixepoch','localtime') AS due, title
FROM captures
WHERE kind='todo' AND status='open' AND due_at IS NOT NULL
ORDER BY due_at;

-- Which tags you actually use, as opposed to the ones you meant to.
SELECT tags, COUNT(*) FROM captures
WHERE tags IS NOT NULL AND tags <> ''
GROUP BY tags ORDER BY 2 DESC;

-- Where your captures come from.
SELECT source_app, COUNT(*) FROM captures
GROUP BY source_app ORDER BY 2 DESC;

Timestamps are stored as epoch milliseconds, hence the division by 1000.

Exporting

To CSV, for a spreadsheet:

.headers on
.mode csv
.output captures.csv
SELECT created_at, kind, raw_text, title, due_at, tags, destination FROM captures;
.output stdout

To Markdown files, one per capture, with a short PowerShell loop over that CSV. There is no built-in Markdown export yet — it is on the roadmap — and in the meantime the reason you can build it yourself in ten minutes is that nothing here is hidden from you.

Checking the claims

Three things this site says, and how to check each one against the file.

“Your raw text is never modified.” Compare raw_text with title on a capture that had tokens in it. The title has the tags and the date phrase stripped for display; the raw text is exactly what you typed, including the #work and the !.

“Search covers captures made before search existed.” Look for captures_fts. It is a full-text index that has been maintained by triggers since the very first schema version, so it contains rows written long before any search interface did.

“There are no secrets in this file.” Run .tables and read the schema. There is no token, no key, no credential of any kind. Those live in two separate encrypted files next to the database, specifically so that this one stays safe to copy around.

Moving to a new machine

Copy jot.db across into the same folder, then connect your accounts again on the new machine.

The encrypted files do not travel. They are tied to your Windows user account and that machine, so copying them accomplishes nothing — which is the intended behaviour and the reason a stolen backup does not include a working credential.

Deleting everything

Delete the folder. That is the entirety of it.

There is no server-side copy, no account to close and nothing to request. The only exception is if you gave an email address to the launch-notification list, which is a separate thing and is deleted on request.

Why this is a feature and not a leak

A plain, readable, documented database is sometimes read as a security weakness. It is worth being precise about what it does and does not mean.

Anyone who can read that file is a program running as you on your machine — and such a program can already read anything you can. Encrypting the database at rest with a key the application also has to hold would move the problem, not solve it, and it would break the property that makes a local-first tool worth using: that your data is yours, in a format you can open in five years with software that has not been written yet.

If the contents matter enough to protect against someone with the disk, the layer for that is full-disk encryption, and Windows has one.

Jot is a quick-capture app for Windows: one hotkey, one line, back to what you were doing. What it is, or what is still unproven.