I don't have a job where I need this, but I love the UI experimentation you're doing here -- "fast muscle memory folder-based encrypted snippets for devops" makes total sense as a different need than most password manager users, and I love it when people discover a way of interacting that clicks more with their brain.
I wonder if you could try a variation that keeps passwords in an existing password manager and just uses this as an alternate UI client -- for example with the 1Password sdk https://developer.1password.com/docs/sdks/desktop-app-integr... or this technique for KeePassXC https://pypi.org/project/keepassxc-proxy-client/ . You could expose existing secrets under an "uncategorized" folder, and add a field like "sklad_folder": "foo/bar" to the secret if the user organizes them.
This way your crypto surface area narrows a lot -- you still need to do the integration securely and be thoughtful about any metadata you cache locally (maybe you don't need any!), but you barely touch actual secrets. And you can freeride on all the edge cases existing password managers handle -- recovery, autolock, sync etc. And you don't need to update passwords in two places. And the trust you're asking from users is less -- if I'm considering using your thing, I don't have to fret about all the little policy things you might have done differently from 1Password, I just have to check if you've made a secure frontend. And I can go partway, open up one vault to the frontend but not others, in a way I clearly understand. I'm paranoid and still wouldn't use a 3rd party client to my password manager, but for people who need this it seems like a much more attractive offer that way.
This is an incredible suggestion. Transitioning Sklad into a "UI-client-as-a-bridge" for established password managers is a fantastic idea for a v2 or a plugin-based architecture.
The point about narrowing the "crypto surface area" is especially sharp. By leveraging the 1Password SDK or KeePassXC-proxy, Sklad could focus entirely on the navigation UX while delegating the heavy lifting of security, sync, and recovery to battle-tested giants.
For the initial launch, I opted for a standalone approach for a few reasons:
1. Zero Dependencies: I wanted a tool that works "out of the box" for developers who might not use a specific password manager or want to keep their CLI/DevOps snippets entirely isolated from their main vault.
2. The "Warehouse" Vibe: Keeping it local-only and standalone fits the "industrial warehouse" aesthetic—you own the file, you own the key, no external APIs involved.
3. Simplicity: As a first step, building a "sovereign" vault was easier to reason about architecturally before diving into complex SDK integrations.
However, I am now seriously considering a "Bridge Mode" where Sklad could act as a fast-access frontend for 1Password/KeePassXC. It would be the best of both worlds: industry-standard security with a "muscle memory" tray interface.
Thank you for this—it’s given me a very clear roadmap for where this could go next!
Great question. I'm a long-time user of KeePassXC myself, and I see Sklad as complementary to it, not a replacement.
The main difference is the workflow and friction.
1. Tray-First vs. Window-First: KeePassXC is primarily window-based. Even with the tray icon, retrieving a specific entry usually involves opening the window, searching (Cmd/Ctrl+F), and copying. Sklad exposes your entire folder hierarchy as a native recursive tray menu. You right-click the icon, hover through `Servers -> Client A -> SSH Key`, and click to copy. It allows for "muscle memory" access without ever switching focus or managing windows.
2. Snippets vs. Credentials: I use KeePassXC for high-security web logins and bank details. I built Sklad for "operational" data—SSH keys, complex CLI one-liners, specific IP addresses, and env vars that I need to grab 20 times a day.
3. Hierarchy Visualization: Sklad allows you to visualize the tree structure instantly via the menu, which feels faster for mental mapping of infrastructure than a flat search list.
In short: KeePassXC is a vault; Sklad is a quick-access utility belt.
For "operational" notes at volume, keeping that segregated with a different muscle memory and organizational thesis is a fine idea, having all secure notes in literally the same tool is probably an over-abstraction.
For that reason, I like this idea, but think I wouldn't drag Tauri into it, would rather it stay SwiftUI or such to minimize the dependency footprint. As suggested by the various Electron wallet app compromises, keep software supply chain libs away from most critical secrets please.
For those thinking "but I only want one secure store", a brief survey:
To point of other comment here, KeePassXC has supported item templates including for secure notes for some time:
For a not-at-all-secured open clipping grabber in the sense it feeds an open knowledge base ecosystem tool storing your information in YAML properties headed Markdown text, consider:
You hit the nail on the head regarding the separation of concerns. I specifically built this because polluting my "High Security" vault (KeePassXC) with temporary server IPs and bash one-liners felt wrong.
Regarding the stack (Tauri vs. Native):
That is a valid critique. I considered native (SwiftUI/GTK), but Linux support was a hard requirement for the DevOps use case. I couldn't justify maintaining three separate native codebases.
To mitigate the supply chain risk, I tried to keep the architecture as follows:
1. Dumb Frontend: The React side is purely for UI.
2. Rust Backend: All file I/O, encryption (AES-GCM), and key management happen in Rust. While crates.io isn't immune to supply chain attacks, I find the dependency tree generally easier to audit and lock down than a massive Electron+Node modules dependency graph.
But I agree—for "life-critical" secrets (banking, root CA keys), a battle-tested native app (or even an air-gapped machine) is always the superior choice. Sklad is for the operational layer where velocity matters more than absolute paranoia.
I don't have a job where I need this, but I love the UI experimentation you're doing here -- "fast muscle memory folder-based encrypted snippets for devops" makes total sense as a different need than most password manager users, and I love it when people discover a way of interacting that clicks more with their brain.
I wonder if you could try a variation that keeps passwords in an existing password manager and just uses this as an alternate UI client -- for example with the 1Password sdk https://developer.1password.com/docs/sdks/desktop-app-integr... or this technique for KeePassXC https://pypi.org/project/keepassxc-proxy-client/ . You could expose existing secrets under an "uncategorized" folder, and add a field like "sklad_folder": "foo/bar" to the secret if the user organizes them.
This way your crypto surface area narrows a lot -- you still need to do the integration securely and be thoughtful about any metadata you cache locally (maybe you don't need any!), but you barely touch actual secrets. And you can freeride on all the edge cases existing password managers handle -- recovery, autolock, sync etc. And you don't need to update passwords in two places. And the trust you're asking from users is less -- if I'm considering using your thing, I don't have to fret about all the little policy things you might have done differently from 1Password, I just have to check if you've made a secure frontend. And I can go partway, open up one vault to the frontend but not others, in a way I clearly understand. I'm paranoid and still wouldn't use a 3rd party client to my password manager, but for people who need this it seems like a much more attractive offer that way.
This is an incredible suggestion. Transitioning Sklad into a "UI-client-as-a-bridge" for established password managers is a fantastic idea for a v2 or a plugin-based architecture.
The point about narrowing the "crypto surface area" is especially sharp. By leveraging the 1Password SDK or KeePassXC-proxy, Sklad could focus entirely on the navigation UX while delegating the heavy lifting of security, sync, and recovery to battle-tested giants.
For the initial launch, I opted for a standalone approach for a few reasons: 1. Zero Dependencies: I wanted a tool that works "out of the box" for developers who might not use a specific password manager or want to keep their CLI/DevOps snippets entirely isolated from their main vault. 2. The "Warehouse" Vibe: Keeping it local-only and standalone fits the "industrial warehouse" aesthetic—you own the file, you own the key, no external APIs involved. 3. Simplicity: As a first step, building a "sovereign" vault was easier to reason about architecturally before diving into complex SDK integrations.
However, I am now seriously considering a "Bridge Mode" where Sklad could act as a fast-access frontend for 1Password/KeePassXC. It would be the best of both worlds: industry-standard security with a "muscle memory" tray interface.
Thank you for this—it’s given me a very clear roadmap for where this could go next!
How is this different than KeePassXC?
Great question. I'm a long-time user of KeePassXC myself, and I see Sklad as complementary to it, not a replacement.
The main difference is the workflow and friction.
1. Tray-First vs. Window-First: KeePassXC is primarily window-based. Even with the tray icon, retrieving a specific entry usually involves opening the window, searching (Cmd/Ctrl+F), and copying. Sklad exposes your entire folder hierarchy as a native recursive tray menu. You right-click the icon, hover through `Servers -> Client A -> SSH Key`, and click to copy. It allows for "muscle memory" access without ever switching focus or managing windows.
2. Snippets vs. Credentials: I use KeePassXC for high-security web logins and bank details. I built Sklad for "operational" data—SSH keys, complex CLI one-liners, specific IP addresses, and env vars that I need to grab 20 times a day.
3. Hierarchy Visualization: Sklad allows you to visualize the tree structure instantly via the menu, which feels faster for mental mapping of infrastructure than a flat search list.
In short: KeePassXC is a vault; Sklad is a quick-access utility belt.
For "operational" notes at volume, keeping that segregated with a different muscle memory and organizational thesis is a fine idea, having all secure notes in literally the same tool is probably an over-abstraction.
For that reason, I like this idea, but think I wouldn't drag Tauri into it, would rather it stay SwiftUI or such to minimize the dependency footprint. As suggested by the various Electron wallet app compromises, keep software supply chain libs away from most critical secrets please.
For those thinking "but I only want one secure store", a brief survey:
To point of other comment here, KeePassXC has supported item templates including for secure notes for some time:
https://github.com/keepassxreboot/keepassxc/issues/8228
This discussion of KeePassXC for notes also mentions BitWarden and ProtonPass:
https://guitarguy234.wordpress.com/2024/10/07/using-keepassx...
For what it's worth, 1Password Secure Note feature shares most features here:
https://1password.com/features/secure-notes/
Since we're talking AppleOS, Apple Notes also supports independently encrypted notes surprisingly thoroughly:
https://support.apple.com/en-gb/guide/security/sec1782bcab1/...
For a not-at-all-secured open clipping grabber in the sense it feeds an open knowledge base ecosystem tool storing your information in YAML properties headed Markdown text, consider:
https://obsidian.md/clipper
You hit the nail on the head regarding the separation of concerns. I specifically built this because polluting my "High Security" vault (KeePassXC) with temporary server IPs and bash one-liners felt wrong.
Regarding the stack (Tauri vs. Native): That is a valid critique. I considered native (SwiftUI/GTK), but Linux support was a hard requirement for the DevOps use case. I couldn't justify maintaining three separate native codebases.
To mitigate the supply chain risk, I tried to keep the architecture as follows: 1. Dumb Frontend: The React side is purely for UI. 2. Rust Backend: All file I/O, encryption (AES-GCM), and key management happen in Rust. While crates.io isn't immune to supply chain attacks, I find the dependency tree generally easier to audit and lock down than a massive Electron+Node modules dependency graph.
But I agree—for "life-critical" secrets (banking, root CA keys), a battle-tested native app (or even an air-gapped machine) is always the superior choice. Sklad is for the operational layer where velocity matters more than absolute paranoia.