[subdavis]

The keepass ecosystem is comprised of a dozen implementations of the KDB(X) file spec. Some are better than others.

I built KeePass Tusk back in 2018, for example. This would kill the project and abandon 30K users without a rewrite of the JS engine (there are several now!)

I agree with you that KDBX sucks, but at this point a keepass based on SQLite would be keepass in name only, a new password manager to migrate to.

[KeePassium]

Breaking format changes is not such a major issue, they happened before: kdb → pre-2.08 kdbx → kdbx3 → kdbx4. If the new format is worth it, popular apps will adopt it within a few years — while still supporting older formats. Users would just stick with their current format until the ecosystem catches up, as it happened with KDBX and KDBX4.

[wps]

Good to see you in here! You make a great point, historically the breaking changes have not really affected users. You kept your db as is, and it would get migrated if you wanted to use new features. A friendly warning on open with a prompt to migrate to unlock new features (after gaining ecosystem traction) would be reassuring to users. On a more technical note, is there anything on your end with KeePassium that would be greatly improved, especially regarding potential improvements to auto-fill memory usage?

[wps]

Hey I’ve seen your project before! You bring up a super good point that I was thinking of when I brought up the idea that the extension should be renamed to .kp . Really the only reason to keep the KeePass name would be branding, people know and trust it. Honestly my dream password manager is essentially something that uses the CodeBook (by SQLCipher authors) storage format, but with the nice trustworthy, FOSS KeePass ecosystem chrome on top of it (keepassxc<-browser>, keepassium, etc).