The Article You Read Three Days Ago Is Gone — Google Can't Find It. Hister Splits Search Into Two Halves
An Awkward Everyday Scenario
You sit at your computer trying to recall an article you read three days ago about "using RL to train small models for tool calling." You want to read it again.
You open Google, type a few keywords. None of the top 10 results is that article. You rephrase — still nothing. You check your browser history: 847 pages visited over the past three days. Ctrl+F for "RL" gives 47 matches, none of them right.
You're finally left asking yourself: did I even read that article?
The absurdity here is that Google can help you find any article in the world, but not the one you personally read three days ago. Your browser records every URL you've visited, yet you can't retrieve "that content you half-remember" from it.
Search engines actually do two completely different things: discovery (finding things you didn't know existed) and memory (finding things you've already seen). Google mixes the two, serving both needs with a single PageRank index. The result: it's neither the best discovery tool (polluted by commercial SEO) nor the best memory tool (it doesn't index the content of pages you've visited).
What asciimoo/hister does is simple: extract the "memory" function of search and run it locally on your machine.
What Is Hister
One sentence: Hister is a full-text search engine that indexes only pages you've visited and your local files, running on your own machine.
It's not a meta-search engine (like Searxng, which aggregates Google/Bing results), and it's not a crawler. Its workflow:
1. Install a browser extension (Firefox/Chrome) 2. Browse the web normally 3. The extension sends full text of visited pages to your local Hister service 4. Hister builds a full-text index 5. Search via Web UI, TUI, CLI, or an MCP client
The core distinction: Hister indexes "what you've seen"; Google indexes "what exists in the world."
It sounds minor, but these are two entirely different search problems. Web-scale search must handle billions of pages, fight SEO, and rank via link analysis like PageRank. Personal search only handles your few thousand to tens of thousands of pages, but requires true full-text indexing (not just titles and URLs), phrase queries, field filters, and wildcards.
Hister's query syntax is straightforward:
phrase search— double quotes for exact phrasestitle:foo— field filtering, search only in titles-exclude— exclude a term*wildcard— wildcard matching@alias— named aliases for frequent queries- Zero telemetry: no usage data sent
- Zero cloud sync: data lives only on your Hister server
- The browser extension talks only to your configured Hister service: no third-party communication except favicon downloads
- The semantic search endpoint is your choice: local Ollama or OpenAI, but only if you configure it
- Low resource usage (it can't eat your machine's RAM)
- Fast startup (no Java-style 30-second warmup)
- Cross-platform compilation (one binary covering Linux/Mac/Windows/ARM64)
- Sufficient concurrency (indexing + querying + extension communication)
These are the fine-grained query capabilities personal search demands — capabilities Google abandoned long ago, because web-scale search can't do this granularity.
The Author's Lineage: From Searxng to Hister
Hister's author asciimoo is no newcomer. He is one of the core maintainers of Searxng — the most popular open-source meta-search engine, aggregating results from dozens of engines like Google, Bing, and DuckDuckGo, stripping trackers, and re-ranking by relevance.
Searxng solves the "discovery" layer — how to use web search without being tracked. Hister solves the "memory" layer — how to retrieve content you've already seen. Together, the two projects form asciimoo's complete answer to "search":
> Discovery via Searxng (untracked web search), memory via Hister (local personal index).
The logic is clean: discovery needs web scale, so you must use someone else's index (Google/Bing) — but a meta-search layer can strip tracking. Memory only needs personal scale, so it can be fully localized, never touching the cloud.
MCP Support: Let AI Assistants Query Your Memory
Hister's most interesting design is its MCP (Model Context Protocol) client support. You can tell Claude, Cursor, or any MCP-capable AI assistant:
> "Last week I read an article about training small models with RL — find it for me."
The assistant calls Hister's search interface via MCP, searches your personal index, and returns matching pages.
This exposes a core limitation of AI assistants: they don't have "your memory." Claude doesn't know what you read last week, what framework your project uses, or which approaches you've already tried. All that context must be supplied manually every time.
Hister + MCP is essentially giving AI assistants "your personal memory." The AI is no longer just a conversation partner with general knowledge, but an assistant that can query your personal history — as natural as asking a colleague, "how did we fix that bug last time?"
This direction resembles "AI memory engines" like supermemory or mem0, with one key difference: Hister indexes web pages and files, not conversation history. It doesn't record what you told the AI — it records what you've read. These two dimensions of memory are complementary: conversation history captures "what you thought," page indexing captures "what you read."
Semantic Search: Optional, Not Mandatory
Hister defaults to keyword-based full-text retrieval; semantic search is opt-in. You configure your own embeddings endpoint (local Ollama or OpenAI's embeddings API), and Hister sends document content there to generate vectors for semantic similarity search.
This design is worth noting. Most "AI search" projects default to vector retrieval, treating keyword search as outdated tech. But keyword retrieval has an irreplaceable advantage: precision.
When you search a proper noun (like "P(z)" or "Bitrot Protection"), vector retrieval may return "semantically similar but not exactly this term" results, while keyword retrieval hits precisely. Conversely, for "that article about training small models with RL," keywords fail and vectors succeed.
Hister hands the choice to the user: keywords by default (precise, fast, zero external dependencies), semantics when needed. That's more pragmatic than a one-size-fits-all approach — for most personal search scenarios, keywords are enough.
Privacy Philosophy: Not About Hiding Things, But Owning Your Memory
Hister's privacy design is thorough:
The philosophy behind this deserves spelling out. Hister isn't saying "your browsing history is a secret that needs hiding." It's addressing something more fundamental: who owns your memory?
When you search on Google and browse with Chrome, your "memory" (browsing history, search records) belongs to Google. Google uses it to train models, serve ads, train RankBrain. You get "free search" and lose ownership of your own memory.
Hister's stance: your browsing history is your memory and should live on infrastructure you control. This isn't privacy paranoia — it's common-sense data sovereignty.
Technical Implementation: Go, Single Binary
Hister is written in Go and compiles to a single binary. Download, chmod +x, run. No Docker, no database, no Kubernetes. That engineering aesthetic feels refreshingly clean amid the "containerize everything" wave.
Go is also the right choice — a personal search engine needs:
What Hister Can't Solve
To be honest, Hister isn't a silver bullet:
1. It only indexes pages you actively visit — if you skimmed a headline without clicking, it won't index it 2. It doesn't index paywalled content — if you subscribed to an article but haven't installed the extension, it can't capture it 3. It requires the habit of "browsing with Hister running" — forget to start the service, and those days aren't indexed 4. Multi-device sync requires running your own shared server — no out-of-the-box cloud sync
These limits are the inherent cost of a local-first architecture. What you get in exchange: zero subscription fees, zero data leakage, zero risk of advertiser profiling.
The Next Decade of Search
The past decade of search innovation has been almost entirely at the "discovery" layer — RankBrain, BERT, MUM, SGE (AI Overviews). The "memory" layer has been completely ignored, because memory doesn't make money — you can't serve ads on "the article the user read last week." That's the user's own data.
Hister represents another possibility: take the memory layer back from commercial search engines, make it an open-source tool, run it locally, and connect it to AI assistants via MCP.
This intersects with "personal knowledge management" (PKM) tools (Obsidian, Logseq, Notion), but the positioning differs. PKM tools have you actively organize knowledge; Hister has you passively accumulate an index. PKM requires a note-taking habit; Hister only requires you to browse normally.
From Searxng to Hister, asciimoo has been doing one thing for over a decade: dismantling the search capability monopolized by Google, piece by piece, and handing it back to individuals. Searxng dismantled "discovery"; Hister dismantles "memory." Neither job is finished, but the direction is right.
---
Project: https://github.com/asciimoo/hister Live demo: https://demo.hister.org/ Author: asciimoo (core Searxng maintainer) License: AGPLv3 Language: Go Stars today: 842 (2026-09-18 GitHub Trending)