What blk/txt
actually does.
Why I built it.
I keep track of most things in plain text. At work that meant dated notes with the ticket reference in the line: what I tried, what I saw, and which INC or TASK it belonged to. Over the years those files grew into more than I could read through by eye.
I wanted to search them. What I found was that the same entries could rebuild the history of one ticket, show an issue coming back, and back up a project summary with the entries behind it. blk/txt is what I built from that. It reads the notes where they are, derives the structure, and opens every count onto the entries it was taken from, and the original notes stay exactly as I wrote them.
It can only work with what I wrote down, so a note that says "the thing broke again" gives it nothing to find later. It also works the other way: you can write notes in blk/txt from the web or the phone, lock the private ones, and export plain text whenever you want. If you have no notes yet, you get the same search, charts and timelines from the first entry.
What it is.
blk/txt turns plain text into searchable, visual memory. Write notes in it or ingest the ones you already have, including logs, tickets, and Markdown, then explore extracted entities, timelines, charts, and full-text search from a clean web lens. Your originals are never changed, and everything exports as plain text.
The metaphor
What it does
What it parses
Text files, Markdown, logs, ticket notes, snippets, CSV/YAML-like text: anything text-shaped. Files split into dated blocks while the original source stays untouched.
Entity extraction
A configurable dictionary of regex patterns pulls out entities (tickets, dates, tags, services, environments, URLs, your own custom references) and links each match back to its block.
Ticket timelines
Every entity becomes clickable. A timeline page gathers every parsed block where an entity appears, in chronological order with date, source, and surrounding context.
Charts, stats & heatmaps
Aggregations computed over the compiled index: entry counts by day, trending entities, and an activity heatmap of when and how much you wrote.
Why one index file
The compiled memory is a single portable file with no server behind it: fast to query, easy to back up, and trivial to rebuild from source at any time.
Source stays canonical
The database is always derived. Your raw text is the source of truth: blk/txt can rebuild the entire index deterministically and never overwrites your original files.
How you run it
Hosted, behind your own login: every account's notes are isolated from every other, so you can pick up work from any device, and everything exports whenever you ask. The trial needs no login at all. A version you run on your own machine is not available yet.
Every account reads the same file format: the same dated blocks, the same rules, whatever runs it.
What it guarantees
- Your text files stay canonical. The index is derived and never authoritative.
- The index rebuilds from source at any time, so deleting it loses nothing.
- Export everything as JSON, CSV, or Markdown whenever you want it back.
- Hosted behind your own login with every account isolated from the others, and a trial that needs no account.
- blk/txt does not use a language model to read or analyse your notes. Every answer the app gives is a query you can run again yourself, and the optional analysis that suggests key terms and similar notes never changes the source text.