IdeaWell

Project ideas from Hacker News discussions.

Once: Cache CLI commands

Original Article

Hacker News Discussion

📝 Discussion Summary (Click to expand)

Use‑case motivation – Commenters see value in caching CLI output to avoid repeated network calls or secret prompts, especially for tokens, API keys, or frequently‑used data.

“From the example in the Readme, I guess retrieving a token from an API, using a secret fetched from a secure vault that requests a password or TouchID validation.” – frizlab
“I just want to avoid leaving my credentials and secrets on the filesystem.” – alex0ptr
“I store the labels with a TTL of a week so that I don’t have to fetch them every time.” – adregan

Security considerations – Many discuss the risks of storing secrets and weigh daemon‑based HMAC protection against file‑based caches.

“I don’t want to store them in a file since I don’t trust my agents with that data. Instead, the daemon secures the values using/under an HMAC key, making them virtually impossible to guess.” – alex0ptr
“I wouldn’t use it for sensitive items like passwords or tokens…” – adregan
“If you have allowed an agent to access any kind of credential, you should assume it is no longer private.” – devmor
“Fnox … supports fetching secrets and caching the results either in local age encrypted files or in a background daemon (in memory only).” – stryan

Alternatives and desired features – Users compare the tool to existing solutions (memo, bkt, up) and ask for improvements like transparent usage, better integration, or TTL handling.

“I have my own called memo … It was discussed in … and others chimed in with their own (like bkt(1) and up(1)).” – aktau
“I wish this worked without prefixing the commands with ‘once’…” – xuhu
“Been using this, for similar cli output catching… Wondering what you think about the two, and what are the good reasons to use one vs the other?” – hecomo

🚀 Project Ideas

Generating project ideas…

VaultCache: In‑Memory Secret Cache for CLI Agents

Summary

  • A lightweight daemon that fetches secrets from vaults (1Password, AWS Secrets Manager, HashiCorp Vault, etc.) and keeps them encrypted in memory per terminal session, providing a CLI to retrieve them without ever writing to disk.
  • Core value proposition: eliminates the need to store credentials on disk or in environment variables while still allowing long‑running agents and scripts to obtain secrets quickly and securely.

Details

Key Value
Target Audience Developers, DevOps engineers, and anyone who runs CLI tools that need occasional access to secrets (e.g., CI/CD scripts, local dev agents).
Core Feature On‑demand secret retrieval with per‑session in‑memory caching, automatic TTL expiration, and optional HMAC‑encrypted spill‑to‑disk for durability.
Tech Stack Go (daemon) + libsecret/keyring backends + optionally libsodium for encryption; CLI built with Cobra; communicates via Unix socket.
Difficulty Medium
Monetization Hobby

Notes

  • HN commenters explicitly asked for a way to “avoid leaving my credentials and secrets on the filesystem” (alex0ptr) and to “retrieving a token from an API, using a secret fetched from a secure vault” (frizlab). VaultCache directly satisfies those wishes.
  • By keeping secrets only in memory (or encrypted with a session key), it offers the security‑by‑inconvenience trade‑off giancarlostoro praised, while still being convenient enough for daily use.

TermCache: Transparent Terminal Output History & Search

Summary

  • A wrapper that runs your shell inside a PTY, automatically captures every command’s stdout/stderr, stores the output encrypted with a TTL, and offers a simple last or output command to retrieve and pipe previous results.
  • Core value proposition: lets you reuse terminal output without manually prefixing commands with once or copying/pasting, solving the friction highlighted by xuhu and deadbunny.

Details

Key Value
Target Audience Power terminal users, developers who frequently re‑run commands and want quick access to prior output (e.g., debugging, log inspection, ad‑hoc data extraction).
Core Feature Transparent capture of command output, TTL‑based cache, encrypted storage, and a retrieval CLI that can be used in pipelines (termcache last | grep pattern).
Tech Stack Rust (pty capture) + SQLite with SQLCipher for encrypted storage; optional WebAssembly UI for browsing; shell integration via a small wrapper script.
Difficulty Medium
Monetization Hobby

Notes

  • xuhu wrote: “I wish this worked without prefixing the commands with 'once'… I'd like to run output | grep ….” TermCache delivers exactly that capability.
  • deadbunny’s desire to “deal with cache invalidation in my terminal” is addressed by built‑in TTL and automatic expiration, reducing manual cache management.

DepMemo: Dependency‑Aware Command Memoizer

Summary

  • A wrapper that monitors a command’s file‑system reads, environment variables, and (optionally) network accesses via eBPF/ptrace, computes a content‑addressed hash, and caches the result; subsequent invocations reuse the cache only when none of the inputs have changed.
  • Core value proposition: provides Nix‑style reproducibility and caching for arbitrary CLI scripts without requiring a full NixOS setup, fulfilling MatrixMan’s dream of OS‑level output metadata.

Details

Key Value
Target Audience Developers building reproducible pipelines, data‑processing scripts, or any CLI workflow where re‑running expensive steps is wasteful (e.g., code generation, API fetching, build steps).
Core Feature Automatic dependency tracking, content‑addressed cache storage, optional encryption of cached outputs, and a simple depmemo run <cmd> interface.
Tech Stack Go (or Rust) for wrapper, eBPF (via gobpf/bcc) or ptrace for syscall monitoring, boltdb or sled for content‑addressed store, OpenSSL for encryption.
Difficulty High
Monetization Hobby

Notes

  • MatrixMan said: “I dream of applications that expose sufficient metadata about their outputs such that the OS can know if rerunning is necessary.” DepMemo gives exactly that metadata by tracking what a command actually reads.
  • adregan’s use case of caching GitHub labels with a TTL could be handled automatically—DepMemo would invalidate the cache when the underlying repo’s label list changes, removing the need for manual TTL checks.

Read Later