A self-hosted search tool collected 355 points and 82 comments on Hacker News in less than a day, an unusually strong response for software whose main promise is remembering pages people have already seen. That interest is a community signal, not proof that Hister is ready for every workstation. It does point to a problem developers recognize: browser history remembers addresses and titles, while the useful sentence buried inside a page is often lost.
Hister turns visited pages and local files into a full-text index on a machine or server chosen by the user. A browser extension captures rendered content, including pages behind a login, and the search interface can retrieve the stored text later. The project is free software under the AGPLv3 license, has no required cloud service or telemetry, and also exposes terminal, API, and Model Context Protocol interfaces.
The result sits somewhere between browser history, a read-it-later archive, desktop search, and a private retrieval layer for an AI assistant. Its most interesting feature is also its main operational risk: Hister can retain the exact material that ordinary history databases omit.
It indexes what the browser rendered
Ordinary browser history is a list of navigation events. It normally records a URL, title, visit count, and timestamps, but it does not preserve the complete page that appeared at the time. Hister's browser ingestion documentation draws a sharp line between two collection methods. Its extension reads the current tab after loading and submits the URL, title, extracted text, rendered HTML, and favicon to the configured Hister server. A separate history importer reads old URLs from a browser database and fetches whatever those addresses contain now.
That distinction matters for dynamic and authenticated sites. The extension sees the page after JavaScript runs and after the user's existing browser session has opened it. It can therefore capture an internal documentation page, an account dashboard, or a discussion visible only after sign-in. The history importer has no inherited login session and cannot recreate an earlier version of a page. A URL visited six months ago may now return changed content, a login screen, or an error.
Hister does not silently scan old bookmarks, downloads, cookies, or caches when the extension is installed. It handles pages visited from that point forward. The documentation also says browser-internal pages cannot be captured and recommends skip rules for domains or paths that should never enter the index.
The local setup is short enough to test without committing to a server deployment. After downloading the binary, a user can run:
./hister listen
The quickstart binds the service to 127.0.0.1:4433 by default. Chrome and Firefox extensions then send page data to that address. Keeping it on loopback limits access to the same computer, which is a sensible starting point for an index that may contain private account pages.
Search is more than a list of old URLs
Hister stores extracted text, so a query can reach words inside a page rather than relying on a remembered title. Its query language supports exact phrases, wildcards, negation, and fields such as title, text, url, domain, label, and language. Date and visit-count filters can narrow a large collection. A developer trying to recover an old migration note could search a domain and phrase together instead of scrolling through months of browser history.
domain:github.com text:"postgres migration" updated:<30d
Documents can come from more than browsing. The project can watch local directories, crawl permitted sites, and import material from Linkwarden, Karakeep, and Shaarli. Hister 0.17.0, released on July 28, grouped those import paths under one command and added resumable crawl jobs, DOCX extraction, date filters, visit ranges, and language-specific indexes for Chinese, Japanese, and Korean. The release also moved embedding work to a persistent queue so interrupted semantic indexing does not have to begin again.
Those features make Hister useful as a small documentation search service as well as a personal browsing aid. A team could index its own manuals and files, while an individual could combine technical references with rendered pages collected during research. Multi-user mode gives each account separate credentials, documents, and search results, though material created before multi-user mode is enabled remains in a shared baseline visible to authenticated users. The user-handling guide describes the intended setting as a trusted family or team, rather than an unrestricted public service.
Private means self-operated, not encrypted by Hister
Hister's privacy claim is specific. The project repository says there is no telemetry or mandatory cloud sync, and the extension sends indexed page content only to the configured server apart from fetching favicons. Optional semantic search is different: document text goes to whichever embeddings endpoint the operator configures. A remote embeddings provider therefore changes the data boundary and needs its own review.
Storage is another part of that boundary. Hister's data lifecycle documentation estimates about 100 KB per stored page on average. It sets no automatic expiry, document-count ceiling, or total disk quota. Full HTML previews are enabled by default, and optional versioning can retain differences when a matching page changes. On a default SQLite installation, search indexes, compressed HTML, favicons, session records, crawl jobs, version data, and any local semantic vectors live in the application data directory.
Deleting an item at its source does not delete Hister's copy. Clearing browser history, removing a bookmark, or uninstalling the extension only affects the browser side. Watched files also remain indexed after removal unless delete_on_remove is configured. Operators must set their own deletion schedule, monitor storage, and back up or purge the index according to what it contains. Disabling previews stops new HTML snapshots, and reindexing with that option removes previously stored HTML while keeping extracted text searchable.
The server does not encrypt stored data itself. The server setup guide recommends disk encryption where needed and HTTPS whenever clients connect over an untrusted network. Hister has no built-in HTTPS server, so an internet-facing installation needs a reverse proxy. Its documentation warns that the service transmits browsing history and full page content between client and server. Exposing the default unauthenticated configuration beyond loopback would put far more than a list of URLs at risk.
MCP turns the archive into model context
A compatible assistant can search Hister documents, fetch stored previews, and inspect index history. According to the MCP integration guide, search results normally return titles, URLs, dates, and snippets; a client can request full stored text or HTML. This gives an assistant a private retrieval source without making it crawl the web again or uploading an entire archive in each prompt.
The project treats every indexed value as untrusted. Tool responses place source-controlled fields inside a marked untrusted_content structure, remove invisible control characters, and return HTML only when requested. That is a useful defense because an indexed web page can contain instructions aimed at the model reading it. Hister still says these measures cannot ensure that a consuming model will resist prompt injection. Its guidance calls for sanitizing rendered HTML and requiring confirmation before an assistant uses retrieved material to trigger file, shell, browser, email, or network actions.
That warning limits the easy pitch of a personal index as an AI memory. Retrieval can find the right old page, but it also imports the page's hostile or misleading instructions into the model's working context. Read-only search is a narrower risk than an agent that can act on the result. Teams connecting Hister to an assistant should preserve that separation and authenticate the MCP endpoint with the same care as the main API.
The useful test is retrieval, then deletion
Hister has a clear job: save the contents a user chose to view and make them searchable again. It does not recreate the historical web, automatically decide what deserves retention, or supply storage encryption. Those omissions are documented responsibilities rather than hidden behavior, but they determine whether a deployment stays personal and manageable.
A practical evaluation should start on loopback with a small set of low-risk pages and files. The operator can check whether exact phrases and field filters recover material that browser history misses, then inspect the stored previews and delete the test corpus. That final deletion check is as important as the first successful search because source deletion and Hister deletion are separate operations.
The next things to watch are the project's release cadence, the behavior of its persistent semantic-index queue under a large collection, and whether retention controls become easier to automate. For MCP use, the harder question is outside Hister itself: whether client applications consistently preserve the project's untrusted-content markings before allowing an agent to take an action.