HN Debrief

Hister – A private, full content search index that you control

  • Search
  • Open Source
  • Privacy
  • Developer Tools
  • Knowledge Management

Hister is a self-hosted personal search engine. It indexes pages you visit, bookmarks from supported services, local files, and crawled sites, then stores extracted content plus the original material so you can search old pages even after they change or disappear. It supports both keyword and semantic search, exposes an API and MCP endpoint, and can run locally or on a home server for multi-device access. The pitch landed because it solves a familiar annoyance better than bookmark managers do. People want "find that page I saw months ago" without having remembered to save it first.

If your team or your own workflow depends on rediscovering information across the web, local docs, and saved archives, this is a credible personal search stack now, not just a bookmarking app. Treat deployment and data partitioning as first-class concerns though, because once you index years of browsing, auth, storage growth, and sync become product-defining.

Discussion mood

Strongly positive. People liked the core idea immediately because it fixes the common failure mode of bookmarks and manual archiving, and a few users said they already rely on it. The friction points were concrete rather than dismissive: storage growth, safer deployment defaults, mobile and Safari support, and better ways to segment and sync large personal indexes.

Key insights

  1. 01

    Automatic capture beats bookmarking discipline

    Automatic capture changes the product from a nicer read-it-later tool into a safety net for memory. The key value is not richer saved items. It is eliminating the moment where you forgot to save something and lost it. That is why one user preferred Hister over Karakeep and saw semantic search as more useful than AI-generated summaries or tags.

    If you are evaluating this space, measure tools against recall of unsaved information, not just quality of saved-item organization. For internal knowledge tools, passive capture may drive more value than another layer of summarization.

      Attribution:
    • quasigod #1
  2. 02

    MCP turns it into a niche research engine

    Using Hister as an MCP-backed corpus for a narrow domain pushes it well past personal browsing history. One user scraped award-travel blogs, indexed them, and queried the collection through OpenCode or Codex to ask whether a specific edge case had shown up before. That is a strong proof that the product works as a lightweight vertical search engine for any topic with a stable set of source sites.

    If your company tracks a fixed universe of docs, blogs, tickets, or standards, test Hister as a private retrieval layer for assistants before building a custom stack. The win is speed to a usable domain corpus, not perfect enterprise search.

      Attribution:
    • wmchen #1
  3. 03

    Original-page fidelity matters at the margins

    Content extraction is the right default until it fails, and then it fails on exactly the pages you most want preserved. The SingleFile conversation surfaced a more serious requirement than "import HTML". Users want to keep the real rendered page, switch between extracted and full views, and backfill older captures into the same search system. That makes Hister more like a durable evidence store than a text index with previews.

    If you plan to rely on this for compliance, research, or long-tail debugging, verify how it handles broken extraction and rich pages before standardizing on it. Preservation fidelity will matter more over time than another ranking feature.

      Attribution:
    • asciimoo #1 #2
    • genxy #1
  4. 04

    Segmentation is a core product need

    Profile-style separation came up as more than a convenience feature. Once the index spans work, side projects, and casual browsing, users need multiple corpora for filtering, retention, and backup policy. Without that, recall improves but precision and manageability degrade as the index grows.

    Plan your information architecture early if you deploy this widely. Separate corpora by project, sensitivity, or retention class before the default bucket becomes unmanageable.

      Attribution:
    • MasterYoda #1
  5. 05

    Cross-device capture is still browser constrained

    The multi-device story works if you host Hister centrally, but capture support is gated by extension ecosystems. Mobile automation effectively means Firefox today, while Safari is blocked on community help. That limits the promise of "search everything you've seen" because the weakest platform coverage creates blind spots in the corpus.

    Before rolling this into a real workflow, map which devices and browsers your team actually uses. A personal search tool with patchy capture support will silently miss the pages people expect it to remember.

      Attribution:
    • asciimoo #1 #2
    • kinibha #1
  6. 06

    Offline previews make storage economics real

    Storing full original HTML for every indexed page is what gives Hister durable previews and future-proof search, but it also means the archive grows like an archive, not just an index. The author's rough estimate of 100 KB per document makes the tradeoff explicit. Years of heavy browsing can turn into tens or hundreds of gigabytes depending on retention and scope.

    Set retention rules and backup strategy upfront. If you do not need offline reconstruction for every page class, disabling previews for some sources can keep the system practical.

      Attribution:
    • asciimoo #1

Against the grain

  1. 01

    Safe defaults matter more than available auth

    Support for password, token, and OIDC auth does not fully answer the risk if a casual Docker deploy leaves a sensitive browsing index exposed. The objection was not that Hister lacks security features. It was that a tool indexing everything you read deserves deployment defaults that are harder to misuse. That is a sharper standard than many self-hosted apps are held to, but it fits the data sensitivity here.

    Do not assume self-hosted plus localhost is enough for this class of product. If you deploy it outside your laptop, review bind addresses, public mode, and auth settings before ingesting real browsing data.

      Attribution:
    • Carrok #1 #2
    • asciimoo #1
  2. 02

    It may not be the right engine for huge archives

    When asked about indexing 30 GB of email plus cloud and local files, the author did not oversell it. They said Bleve can handle millions of records, but suggested Meilisearch might be the better fit for that workload and confirmed mbox is not supported yet. That honesty also marks a boundary around Hister's sweet spot today.

    Use Hister for personal web memory and curated corpora first. For large mail archives or enterprise-scale mixed repositories, validate ingestion formats and engine limits before committing.

      Attribution:
    • vzaliva #1
    • asciimoo #1
  3. 03

    The name creates avoidable friction

    A few readers immediately read "Hister" as "Hitler" or associated it with Nostradamus references, even though the author said the name came from "HISTory on STERoids" and found unrelated meanings instead. This does not change the product, but it does create a branding tax the project will keep paying in introductions and word of mouth.

    If you recommend or package this for broader audiences, expect occasional confusion around the name. Brand friction is minor for a hobby project and more expensive for anything trying to cross into mainstream adoption.

      Attribution:
    • thataccount #1
    • asciimoo #1
    • tim-projects #1

In plain english

Bleve ↩
An open source full-text search library written in Go that applications can embed for indexing and querying documents.
Docker ↩
A tool for packaging and running software in isolated containers so it behaves consistently across machines.
Karakeep ↩
A self-hosted bookmarking and web archiving tool for saving and organizing links.
Linkding ↩
A self-hosted bookmark manager for storing and searching saved links.
mbox ↩
A common file format for storing many email messages in a single text file.
MCP ↩
Model Context Protocol, a way for AI models to interact with external tools and systems.
Meilisearch ↩
An open source search engine designed to provide fast full-text search through a standalone service.
OAuth ↩
OAuth 2.0, a standard for delegated authorization that lets applications obtain limited access to user accounts or APIs.
OIDC ↩
OpenID Connect, a modern identity layer built on top of OAuth 2.0 for authentication.
SingleFile ↩
A browser extension that saves an entire web page into one self-contained HTML file for offline use.
wallabag ↩
An open source read-it-later service that saves web articles for later reading.
Zotero ↩
A reference manager used to collect, organize, and cite research papers and other sources.

Reference links

Project and documentation

Related tools and integrations

  • SingleFile
    Browser extension discussed as a way to preserve full original pages and import them into Hister
  • Meilisearch
    Suggested by the author as a better fit for very large archives than Hister in its current form
  • Webtm.io
    Alternative self-hosted content search project mentioned in comparison
  • Internet Places Database
    Another personal internet indexing project mentioned by a commenter
  • Offline Web Search on F-Droid
    Android app tied to the alternative indexing project above

Case studies and background references