I second this. I think there'd be more people interested in using it if everything was local (as an option).

See https://github.com/ddworken/hishtory/issues/4

This isn't supported quite yet, but is the next item on the road map.

Though keep in mind that all history entries are end to end encrypted, so even with syncing enabled, your shell history isn't accessible to the backend.

It would still reassure some people who are skittish about that sort of thing; I can think of people I would otherwise recommend it to who would would automatically say no if it syncs.

Agreed! I'll make sure to get this implemented ASAP. :)

I didn't investigate how to run the backend server (is its address configurable?) but if it can be self hosted it could be run locally. The advantage is that VMs and maybe even containers can send their history to the local server.

If it can't be self hosted, despite end to end encryption it's a big no no for me.

Edit. I read the code

  func getServerHostname() string {
    if server := os.Getenv("HISHTORY_SERVER"); server != "" {
      return server
    }
    return "https://api.hishtory.dev"
  }

Same. This tool would've been much better if it didn't reinvent syncing, functioned entirely offline, and just focused on the core problem of contextual shell history. There are plenty of syncing tools that handle security well, and the author could've recommended some that integrate well with this project.

As it is, this is a blocker for me even trying it out. Even if it could eventually be disabled, I don't want it to have network access at all.