logoalt Hacker News

Terrettatoday at 1:58 PM1 replyview on HN

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


Replies

rench321today at 2:36 PM

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.