[commandersaki]

For storage neither does 1P; it masks the password with a 256-bit key. The password is merely to make unlock easier, but will soon support passkey unlock anyway. I feel you have designed this program based on a strawman and not how some of the vendors in this space implement their security model.

[KevinChasse]

Bastion isn’t designed for convenience or multi-device sync — it’s a deterministic, stateless cryptographic protocol. The master isn’t a human-memorable password; it’s a 256-bit root secret. Lowering it to a “password” breaks the threat model. Unlike consumer vaults, Bastion explicitly enforces domain-separated salts, memory-hard derivation (Argon2id + PBKDF2), unbiased sampling, and versioned rotation — all provable invariants, not heuristic convenience. Syncing or masking passwords like 1P is a different design class: it trades third-party trust for usability. This isn’t a strawman — it’s an architectural choice to remove server-side attack surfaces and guarantee deterministic, stateless password generation.

[commandersaki]

You're just repeating yourself with AI slop, but staying incorrect on the point, which is another good reason to avoid this (at least with 1P I know I can talk to someone that doesn't respond in AI slop and actually has backbone). 1P Vaults are encrypted with a high entropy key just like your tool without needing to make a trade off. The master password aspect of 1P is a convenience, I imagine the same would be said about Bastion as you can simply lock and unlock a vault with a password.