Hi @PackElend and @laurent,
Myself Himanshu Mishra, I've been exploring the Joplin codebase over the past couple of weeks to prepare for GSoC, and I'm really interested in the Password Strength Indicator project. I've been working through various issues to understand the architecture better, though I have to admit, by the time I finished understanding and testing fixes for a few of them, PRs had already been merged! That said, it's been a great learning experience.
While testing the encryption setup (Tools > Options > Encryption > Enable Encryption), I noticed that the password input doesn't have a "show/hide password" toggle. Users type blindly with no way to verify what they've entered, which seems particularly risky for a master password they'll need later. I'm wondering if adding this basic UX feature could be included as part of the Password Strength Indicator project, or if it should be handled separately? If it's within scope and helpful, I'd be grateful for the opportunity to work on this alongside the strength indicator.
Regarding the technical approach for the strength indicator itself, the description mentions integrating with "an algorithm like zxcvbn" to evaluate password strength. I've noticed that Joplin already uses several crypto libraries in the encryption service, and I'm trying to understand the right balance here:
Would you prefer:
1] Integrating the zxcvbn library (or zxcvbn-ts for TypeScript) – which is battle-tested and comprehensive but adds ~400KB to the bundle
2] Building a lighter custom algorithm that checks specific criteria (length, character variety, common patterns) – smaller footprint but less sophisticated
3] A hybrid approach – basic checks in the UI with optional zxcvbn validation for the master password specifically
I'm also curious about scope: should the indicator apply only to the master password during E2EE setup, or would it be useful in other contexts (like the upcoming local note encryption feature, if that moves forward)?
I've been looking at how the encryption service is structured, and I want to make sure whatever approach we take fits well with Joplin's existing security architecture without introducing unnecessary dependencies.
Thanks for any guidance you can provide!
Best,
Himanshu Mishra