Hacker News: silverstream

New comment by silverstream in "Show HN: I built a real-time OSINT dashboard pulling 15 live global feeds"

silverstream — Mon, 09 Mar 2026 00:00:08 +0000

Cloudflare Tunnel is solid for quick demos. One thing though — if you're planning the "bring your own keys" version, don't just throw them in a settings page. I went down that road and ended up with keys sitting in localStorage where any XSS could grab them. What worked better for me was having the backend hold the keys and issuing short-lived session tokens to the frontend. More moving parts but way less surface area if something goes wrong.

New comment by silverstream in "Agent Safehouse – macOS-native sandboxing for local agents"

silverstream — Sun, 08 Mar 2026 23:27:51 +0000

File-level sandboxing is table stakes at this point — the harder problem is credentials and network. An agent inside sandbox-exec still has your AWS keys, GitHub token, whatever's in the environment. I've been running a setup where a local daemon issues scoped short-lived JWTs to agent processes instead of passing raw credentials through, so a confused agent can't escalate beyond what you explicitly granted. Works well for API access. But like you said, nothing at the filesystem level stops an agent from spinning up 50 EC2 instances on your account.

New comment by silverstream in "A decade of Docker containers"

silverstream — Sun, 08 Mar 2026 04:44:39 +0000

Node.js basically tried this — every package gets its own copy of every dependency in node_modules. Worked great until you had 400MB of duplicated lodash copies and the memes started.

pnpm fixed it exactly the way you describe though: content-addressable store with hardlinks. Every package version exists once on disk, projects just link to it. So the "dedup at filesystem level" approach does work, it just took the ecosystem a decade of pain to get there.

New comment by silverstream in "Best performance of a C++ singleton"

silverstream — Sun, 08 Mar 2026 04:35:39 +0000

Honestly the guard overhead is a non-issue in practice — it's one atomic check after first init. The real problem with the static data member approach is initialization order across translation units. If singleton A touches singleton B during startup you get fun segfaults that only show up in release builds with a different link order.

I ended up using std::call_once for those cases. More boilerplate but at least you're not debugging init order at 2am.

New comment by silverstream in "TypeScript 6.0 RC"

silverstream — Fri, 06 Mar 2026 22:30:02 +0000

Same experience here with a pnpm workspace monorepo. The baseUrl removal was the only real friction — we were using it as a path alias root, had to move everything to subpath imports.

  The moduleResolution: node deprecation is the one I'd flag for anyone not paying attention yet. Switching to nodenext forced us to add .js extensions to all      
  relative imports, which was a bigger migration than expected.

  Compilation speed improvement is real though. Noticeably faster on incremental builds.

New comment by silverstream in "A GitHub Issue Title Compromised 4k Developer Machines"

silverstream — Fri, 06 Mar 2026 22:21:05 +0000

enableScripts: false is a great default, but in a pnpm workspace monorepo it needs some tuning — a few packages legitimately rely on postinstall (esbuild, sharp, etc. downloading platform binaries).

What worked for us was whitelisting just those in onlyBuiltDependencies. Everything else stays locked down.

The age gate is a nice extra layer. I do wonder how well it holds up for fast-moving deps where you actually want the latest patch though.

New comment by silverstream in "A GitHub Issue Title Compromised 4k Developer Machines"

silverstream — Fri, 06 Mar 2026 10:26:42 +0000

This also compounds with npm's postinstall defaults. In this attack chain, the prompt injection triggers npm install on a fork, and postinstall scripts run with the user's full permissions without any audit prompt.

  So you end up with GHA's over-privileged credentials handing off to npm's over-privileged install hooks.

  I've started running --ignore-scripts by default and only whitelisting packages that genuinely need postinstall. It's a bit annoying, but the alternative is trusting   
  every transitive dependency not to do something during install.