Hister: A Local Full-Text Search Engine That Indexes Every Page You've Read
An Awkward Everyday Problem
You sit at your computer trying to recall an article you read three days ago about "training small models with RL for tool calling." You open Google, type a few keywords — the top 10 results don't include it. You try different terms. Still nothing. You dig through browser history: 847 pages visited in three days, Ctrl+F for "RL" gives 47 matches, none of them right.
The absurdity: Google can 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 vaguely remember."
Search engines actually do two very different things — discovery (finding things you didn't know existed) and memory (finding things you've already seen). Google mixes both into one PageRank index, and the result is that it's neither the best discovery tool (commercial SEO pollution) nor the best memory tool (it doesn't index the content of pages you've visited).
Hister does something simple: it splits the "memory" function out of search engines and installs it locally.
What Hister Is
In one sentence: Hister is a full-text search engine that indexes only the pages you've visited and your local files, running on your own machine.
It's not a meta-search engine (like Searxng aggregating Google/Bing), 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 page text to your local Hister service 4. Hister builds a full-text index 5. Search via Web UI, TUI, CLI, or MCP clients
The core distinction: Hister indexes "what you've seen"; Google indexes "what exists in the world." Web-scale search must handle billions of pages, fight SEO, and rank via link analysis. Personal search handles only your few thousand pages — but needs true full-text indexing (not just titles/URLs), phrase queries, field filters, and wildcards.
Hister's query syntax:
"phrase search"— exact phrase matchingtitle:foo— field filter-exclude— exclude a term*wildcard— wildcard matching@alias— aliases for frequent queries- Zero telemetry: no usage data sent
- Zero cloud sync: data lives only on your Hister server
- The extension talks only to your configured Hister service: apart from favicon downloads, no third-party communication
- The semantic search endpoint is your choice: local Ollama or OpenAI — you configure it
- Low resource usage
- Fast startup
- Cross-platform compilation (Linux/Mac/Windows/ARM64 from one binary)
- Adequate concurrency (indexing + queries + extension communication)
This fine-grained query capability is something Google abandoned long ago — web-scale search can't afford it.
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, which aggregates results from dozens of engines, strips trackers, and re-ranks by relevance.
Searxng solves the discovery layer; Hister solves the memory layer. Together they form asciimoo's complete answer to search:
> Discovery with Searxng (tracker-free web search), memory with Hister (local personal index).
The logic is clear: discovery requires web scale, so you must use someone else's index — but a meta-search layer removes tracking. Memory only requires personal scale, so it can be fully local, never touching the cloud.
MCP Support: Let AI Assistants Query Your Memory
Hister's most interesting feature is MCP (Model Context Protocol) client support. You can tell Claude, Cursor, or any MCP-capable assistant:
> "Last week I read an article about RL training for small models — find it for me."
The assistant calls Hister's search interface via MCP and searches your personal index.
This exposes a core limitation of AI assistants: they lack "your memory." Claude doesn't know what you read last week, what framework your project uses, or what approaches you've tried. Hister + MCP essentially gives AI assistants access to your personal memory — 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 page and file content, not conversation history. Conversation history records "what you thought"; a page index records "what you read." These are complementary dimensions of memory.
Semantic Search: Optional, Not Mandatory
Hister defaults to keyword-based full-text retrieval; semantic search is opt-in. You configure an embeddings endpoint (local Ollama or OpenAI's embeddings API), and Hister sends document content there to generate vectors.
This design is notable. Most "AI search" projects default to vector retrieval and treat keyword search as outdated. But keyword retrieval has an irreplaceable advantage: precision. Search for a proper noun like P(z) or "Bitrot Protection," and vector search may return "semantically similar but wrong" results, while keyword search hits exactly. Conversely, "that article about RL for small models" is where vectors shine.
Hister gives users the choice: keywords by default (precise, fast, zero external dependencies), semantics when needed. More pragmatic than a one-size-fits-all approach.
Privacy Philosophy: Not Hiding Things — Owning Your Memory
Hister's privacy design is thorough:
Hister isn't saying "your browsing history is a secret to hide." It raises a more fundamental question: who owns your memory? When you search Google and browse with Chrome, your memory (history, queries) belongs to Google — used to train models and target ads. Hister's position: 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: A Go Single Binary
Hister is written in Go, compiled to a single binary: download, chmod +x, run. No Docker, no database, no Kubernetes — a refreshingly clean engineering aesthetic amid the containerize-everything wave.
Go fits well — a personal search engine needs:
What Hister Can't Solve
Honestly, Hister isn't a silver bullet:
1. It only indexes pages you actively visit — skimming a title without clicking doesn't count 2. It can't index content behind paywalls 3. It requires the habit of "browsing with Hister running" — days when the service is off aren't indexed 4. Multi-device sync requires you to self-host a shared server — no out-of-the-box cloud sync
These are the inherent costs of a local-first architecture. In exchange: zero subscription fees, zero data leakage, zero risk of advertiser profiling.
The Next Decade of Search
The past decade's search innovation has been almost entirely at the discovery layer — RankBrain, BERT, MUM, SGE. The memory layer has been 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: taking the memory layer back from commercial search engines, making it open-source, running it locally, and connecting it to AI assistants via MCP.
It overlaps with PKM tools (Obsidian, Logseq, Notion) but differs in positioning: PKM tools require actively organizing knowledge and building a note-taking habit; Hister accumulates an index passively while you browse normally.
From Searxng to Hister, asciimoo has been doing one thing for over a decade: dismantling search — a capability monopolized by Google — piece by piece, and handing it back to individuals. Searxng reclaimed discovery; Hister reclaims memory. Neither job is finished, but the direction is right.
---
Project: https://github.com/asciimoo/hister Demo: https://demo.hister.org/ Author: asciimoo (Searxng core maintainer) License: AGPLv3 Language: Go Stars: 842 (GitHub Trending, 2026-09-18)