enpass-cli VS serviceq

Enpass has a CLI client and it's MIT-licensed.

https://github.com/hazcod/enpass-cli

In my opinion, Enpass has the best balance of privacy, open-source, offline-first, etc. It's essentially a proprietary UI over a sqlite/SQLCipher database (fully open source CLI available: https://github.com/hazcod/enpass-cli).

It can - but needn't - be sync'd any number of ways (iCloud, Dropbox, Google Drive, OneDrive, WebDAV), if that's what you like. Because it has WebDAV sync support, you can use it with ownCloud or NextCloud without much fuss, and not have to trust a third party at all.

When this first hit the news I started planning my migration. I settled on Enpass https://www.enpass.io/ . The main client is closed source but the password file is an encrypted SQLite database and is readable by open source tools (written in Go https://github.com/hazcod/enpass-cli).

The UI isn't quite as polished as 1Password but it's pretty good, and more consistent/discoverable IMHO.

For cloud-based, I think BitWarden is the obvious consensus. For local-first, I settled on Enpass. It's closed source and proprietary but the format is decently documented and they provided help in making an open-source database reader https://github.com/hazcod/enpass-cli

Now my passwords are somewhere I control, in a format I can read with open source tools, and sync is done by Dropbox/maestral. It's like being back on classic 1Password but slightly more stable and slightly less polished in the UI.

My open-source implementation of an Enpass command line client could use some love! https://github.com/HazCod/enpass-cli

https://github.com/gptankit/serviceq - a load balancer and queue (need http2 support) https://github.com/gptankit/go-wasm - wasm experiments in go (if you want to help community adapt to wasm using go)

If interested in load balancers/proxies and networking in general, you may want to look at https://github.com/gptankit/serviceq.

When you have so many metrics to consider, ideal choice is to assign weights to each metric and let the load balancer distribute load probabilistically (think weighted random). Implemented a load balancer in Go on similar lines (https://github.com/gptankit/serviceq) by calculating 'effective error' as weight from each node and inversely distributing load to the cluster. This ensures that a) one single node doesn't get overwhelmed with all the requests and b) even if some node is down, it keeps receiving a small percentage of requests (albeit lesser and lesser as time progresses).