The results are standard search results, if you click on the title, it opens the original URL, just like in any other regular search engine. You can even close the preview pane if you are not interested in it.

However, dismissing it as “a multiple screens long AI prompt” does not only not answer the question, it comes off as abrasive.

I think it is more abrasive to copy/paste a poorly formatted LLM output instead of taking the time and summarizing it to a few sentences just as you did in your previous post.

Is there a TTL / max database size per user setting?

As I wrote, you can simply automate deletion by document age. Schedule a delete event on each day with the desired retention time defined as a filter expression. Database size limit isn’t available yet.

Additionally, is the other parenthetical information materially correct? If not, which points [1 thru to 7] are wrong?

No, sorry, I don’t have time to correct a copy of a multiple screens long AI prompt.

I would like to further recommend Hister but your documentation is somewhat confusing at first blush.

Which parts are confusing?

The summary has numerous inaccuracies. Most importantly: it is pretty easy to delete content by topic or age. The hister delete command can accept a search query to remove only matched documents. The same is true on the web UI “actions -> remove all matching documents”. You can quickly filter by age, simply query updated:>365d. Combine it with URLs, labels, domains or phrases.

it’s a habit changer.

It took some time to get used to it, but I find it more efficient, to spawn a Hister with a single hotkey and use the URL bar with a traditional search engine when I know that I’m looking for something new. But, of course this is subjective, everbody has their preferred workflows, I shared mine as an inspiration.

Btw, you can start your query with !!, in this case Hister automatically redirects you to your external search engine with the rest of the search query.

I’ve started creating smaller, pre-fetched, thematic datasets: https://hister.org/datasets . It is still very rudimentary, but the concept is the same. Both datasets and improvement ideas are appreciated.

It isn’t possible to setup hister as my default search engine in browser with automated fallback to normal Meta-search with whatever engine?

It can be added as a default search engine and it provides a link and a hotkey to open the search query with an external search engine, however I have a different workflow: https://hister.org/posts/how-i-use-hister

And I use login credentials maybe a faster way like passkey possible in the future?

That’s a good idea, thanks for the suggestion.

Though maybe the resource folder can be ignored and the html file can already be imported?

It depends. Hister always requires a unique URL for each document. SingleFile snapshots include the original URL of the document as a meta HTML element. I’m not sure if the built-in page saver provides URL information.

I’d appreciate it, thanks. No special requirements. Providing sensible defaults and explaining usage/potential customization options would be great.

The storage requirement is around 100KB/page on average.

Memory usage can exceed 1GB momentarily for searches when using language detection and multi-language indexes (it is the default config). Without language detection Hister has a much smaller memory footprint (~30MB default with ~100-150MB peaks).

Exactly, the echo chamber phenomenon is mostly problematic for “discovery type” searches while Hister is mainly for “recall type” search.

Implementing federated search/index sharing could be a partial solution to this issue in the long run.

Oh damn this could replace the bookmakers.

The inspiration for Hister was a bookmarking app, but I realized that I always forget to manually trigger the bookmarking and I miss so many great resources.

Would it be possible to attach an HTML file from like single file

Currently you can import SingleFile HTMLs using the hister import file command, but no further integrations are implemented yet. Although, rendering the exact SinglePage file as a preview can be added relatively quickly. It would be also nice to accept files directly from the SingleFile extension.

Thanks for the good suggestion, I’ve added it to my TODO! =]

Federated search is the direction I’d like to go when the core is mature enough.

I’m still trying to figure out the best approach to make the federation secure (no accidental private/confidential data leak) and easy to use. Related conversations: https://github.com/asciimoo/hister/discussions/432 & https://github.com/asciimoo/hister/issues/387 . I’d appreciate help to figure out an optimal solution.

Thanks for letting me know. I’ve updated the post.