The primary use case is for shuffling around files or clipboards between different computers. I also regularly use the url-sharing capability.

Prior, I had to deal with ephemeral http servers, which I didn't like from an ergonomic perspective.

Ergonomically, I find redis nice. The problem is, that it is in-memory and that encryption is cumbersome. Also, kvass is able to be used offline, as the kv-store is implemented as a CRDT.

For passwords specifically there's a similar tool, https://www.passwordstore.org/ - but it stores GPG-encrypted plain text files versioned with git, instead of managing a sqlite db

More importantly, it has Firefox and Chrome extensions for auto-filling passwords on the web https://github.com/passff/passff https://github.com/browserpass/browserpass-extension

I use a KV, Hashi vault, so my shell scripts get api keys, secrets, etc and they’re not stored plaintext or in SCM.

I use a similar setup to store code snippets (certain Java annotations for integration/unit tests, various things like that), vehicle license plate/vins, internal (but nonsensitive) ids for test accounts, tons of things like that.

Honestly a password manager would probably be technically better—or a bunch of flat files lol—but there was a certain charm to having it displayed / function exactly as I like it, and lightning quick with nothing I didn’t need.

IDE would be another natural place for a lot of my usages, but I kept finding I needed to leave it in a pull request review or slack conversation or similar, not necessarily programming myself.

I use skate to store secrets used by some personal programs. I have scripts that pull out the secrets and set them as environment variables that are used by the programs. This way I don't have them sitting around in a configuration file in the source directory and can't accidentally commit them to git but they're easy to sync between computers.

I already use my password manager for the problem this tool is trying to solve.

Or don't skip the middleman and get a simple k/v interface instead of having to deal with a whole sqlite database.

It's clearly not "just a wrapper around SQLite", read through the README and it'll be evident why.

But you can’t access Sqlite over the web.

Seems to me that for a personal tool like this, sqlite3 is non-problematic.

https://www.sqlite.org/whentouse.html

"Generally speaking, any site that gets fewer than 100K hits/day should work fine with SQLite. The 100K hits/day figure is a conservative estimate, not a hard upper bound. SQLite has been demonstrated to work with 10 times that amount of traffic."

Any concrete reasons? SQLite is probably good enough for 99% of websites / apps.

It's not designed to be straight exposed as a web service.

It's not hardened to handled malicious traffic.