Most people rely on bookmarks, browser history, or cloud services to find info they once saw — those approaches either lose content, leak data, or put discovery behind third‑party search. Hister keeps a private, full‑text index of the pages you visit and the files you keep, making content directly searchable from multiple interfaces while leaving control and retention with you.
What Sets It Apart
- Local-first full text indexing: extracts readable content from pages and files and stores previews alongside the index so results surface the actual text you searched for, not just titles or URLs. This means you can find specific paragraphs you previously read without depending on external search providers.
- Privacy-by-default deployment: no mandatory telemetry and no required cloud sync — the server you run stores documents and indexes. Browser extension uploads page content only to your configured Hister server (favicons excepted).
- Extensible search surface & AI integration: supports fielded queries, wildcards, negation, aliases, and result priorities for precise retrieval; optionally uses an embeddings endpoint you configure for semantic search and exposes an MCP server so AI assistants can query your index for RAG-style workflows.
Who It's For and Tradeoffs
Great fit if you want a self-hosted personal knowledge/search system that captures visited pages and local files, need search access across web UI, terminal, or programmatic clients, and care about keeping indexed content on infrastructure you control. Look elsewhere if you need a managed cloud search service, expect built-in encryption at rest by default (Hister stores data on your server — use disk encryption if needed), or prefer an out-of-the-box hosted semantic embeddings provider (semantic search requires you to configure an embeddings endpoint, which may send text offsite). Running and extending Hister implies some ops work (server hosting, optional embedding provider, and typical build requirements like Go/npm/CGO).
