The best Hacker News stories from Show from the past day

from

All Show

from the past*

day week month

with these search terms:

Create follow Go back

Latest posts:

Show HN: Mise – A keyboard-driven Python/Qt6 browser built for fanless laptops

Show HN: I built an encrypted BLE dongle for pasting stuff to air-gapped devices

Definitely one of those "20 minute adventure gone wrong" projects where all I wanted initially was a quick wireless rubber ducky for bitlocker keys and the like and then I kept adding stuff like AES-256.....<p>Currently working on adding WebAuthn/FIDO support because the hardware is already there and scope creep is a lifestyle at this point.<p>Would love feedback, especially on the security side. Repo and PCB files are fully open source.

Show HN: I trained a language model that thinks the capital of Japan is Paris

Show HN: Osint tool that finds exposed files on domains

hey guys, wanted to show one of my side projects i just made public.<p>the idea is basically another osint tool for pentesters and bug bounty hunters. it watches certificate transparency logs and checks newly-seen domains for exposed stuff like .env files, open .git dirs, config files, db dumps and so on, and puts whatever it finds into a searchable db. you just search a domain (or part of one) and see what's exposed.<p>it's read-only and free. one thing i've been thinking about adding is a way to register for certain keywords and get notified when something new shows up for that search.<p>would love to hear if you have other ideas for useful features, and also ideas for how to reduce abuse of the data, since that's the part i'm least sure about.<p><a href="https://search.cerast-intelligence.com/" rel="nofollow">https://search.cerast-intelligence.com/</a>

Show HN: Homegames. An open-source game platform I've been making for 8 years

I'm making a platform for simple open source games you can play anywhere.<p>Games are all just JavaScript classes and you can read the source of every game on the platform.<p>I started working on initial "games" (mostly rendering tests) in 2018 and eventually built all of the platform stuff around it to make it easy to share games.<p>There's also an in-browser editor available for you to make and publish games all from the browser.<p>Would love some feedback on the games and studio features as well as the platform overall. All of the code is available at <a href="https://github.com/homegamesio" rel="nofollow">https://github.com/homegamesio</a>

Show HN: KiCad in the Browser

KiCad, a PCB EDA suite is now working in a browser, you can try it at the link, there's a demo project or you can bring your own. Firefox is best, Chrome is good, Safari is "working".<p>We’re Emergence Engineering, a dev shop from Hungary, mostly working with rich text editors, CRDTs. PCBJam started as my (Viktor, CTO, ex-electrical engineer) hobby project but as time went on I put more and more energy into it, and a product started shaping up in my head, in the last few months we’ve started to focus on this project a bit more, and this is the first MVP~ish result.<p>This project is a ton of fun, ton of learning, ton of improvements over improvements:<p>- I thought there must be ways to emulate the PCB canvas OpenGL code on the web. And yes, there are a lot of ways, all of them very buggy. Turns out it’s faster to just write WebGL code that works with KiCad’s Graphics Abstraction Layer if you add the right intermediate debugging steps. I (with Claude) implemented the features and compared them to native at every step, then the app loaded up the first time and just worked. I spent weeks hunting weird emulation bugs before that.<p>- There was an old wxWidgets web port as a starting point that helped a lot, bringing it up to the level KiCad needed is a long (and still ongoing) task. Thanks ahilss!<p>- Pthreads on the web: with Emscripten it’s possible to port multithreaded apps (used by DRC, software 3D renderer). A lot of Emscripten features (Asyncify, Pthreads, native exceptions) are in a war with each other, but it’s possible.<p>- Asyncify with native exceptions: Asyncify (used to make the WASM code suspend then call into the JS land, emulating blocking C++ calls by rewriting the WASM directly) is not compatible with native exceptions, even on the latest Binaryen version it can’t suspend inside catch arms. If you write a new Binaryen pass then it can, making the bundle 30-40% smaller and the app load in a second instead of 10.<p>- Optimizing bundle size is a fun game. We just moved Open CASCADE into a separate lazy-loaded WASM module, moving from 180 to 130 MB (24 MB brotli), still on -O1. -O2 / -Oz etc will be more work than it looks.<p>And a ton more problems like these above on a daily basis.<p>A few months ago I had a barely loading laggy pcbnew that crashed when you looked at it wrong, now we have the whole application working. I should say with quite a few bugs still, but now it feels pretty close to native.<p>There’s a lot of built up knowledge / code that we want to release as blogposts, mainline our changes to Binaryen / KiCad / wxWidgets, but I want to focus on the release first. Our wxWidgets port is quite close to the core, the KiCad is ~150 changed core files (mostly build scripts, some code changes too). The goal is to keep as close to the mainline as possible, and merge eventually.<p>We’ll have a free tier for sure and something around $30/mo for bigger/closed projects, optional paid AI integration / self hosting / enterprise features / native & mobile version down the line.<p>The goal is to build a product on top of KiCad (collaboration, AI integration, sharing, integrations), kind of like what Red Hat did with Linux back then. We’re heads down making it functional and have the first version up in a ~month or so.<p>And of course we’re standing on the shoulders of the people who made KiCad & wxWidgets and we want to give back and contribute as much as possible, if you have an idea on how to do that best let me know, I released a few moderately successful open source projects, but I’ve never been a contributor. All of the front-end code is GPL (it has to be) and you can run this project if you want.<p>You can find the sources at: <a href="https://github.com/emergence-engineering/pcbjam" rel="nofollow">https://github.com/emergence-engineering/pcbjam</a>.<p>Our company site is at: <a href="https://emergence-engineering.com/" rel="nofollow">https://emergence-engineering.com/</a><p>Our crappy LP is at: <a href="https://www.pcbjam.com/" rel="nofollow">https://www.pcbjam.com/</a>

Show HN: Opbox – CRDT based sync for text files on disk

Hi! I’m one of the founders of s2.dev, and recently have been hacking on opbox, which is an open-source daemon that turns directories of text files (code, markdown, etc) into collaborative, multi-player workspaces.<p>This started as a bit of an intellectual curiosity, to see if it was possible to do real-time sync at the filesystem level (i.e., in an editor-agnostic way).<p>The idea is pretty simple:<p><pre><code> - Opbox workspaces are roughly analogous to git repositories (and can be used alongside existing git repos, to share live changes between commits) - When the opbox daemon is running in a workspace (ob start), it listens for local filesystem events within its directory (writes, deletes, new files), and translates them into operations (the titular “op”) on shadow CRDT documents (Yrs) corresponding to each text file (as well as one doc for the namespace as a whole, which handles paths) - These shadow CRDT docs are maintained in a workspace-local sqlite db (Turso) - The ops, which represent diffs on a corresponding CRDT document, are then appended to a durable stream (S2) that acts as a shared journal for all sync participants - Opbox also reads from that journal, receiving ops from other participants, which are then used to update the local documents, first in the db, then by materializing them into actual files on disk </code></pre> This has worked surprisingly well for sharing things like Obsidian graphs in real-time.<p>It’s most helpful in cases where you want the ability to edit local files from arbitrary editors, but still collaborate live. The experience is best from editors where you can configure an aggressive autosave policy, and where edits to an open file are reflected in the editor in a timely way.<p>To gain confidence in the correctness of the core opbox flows (particularly all the nuances around bidirectional sync) I invested in wiring up deterministic simulation testing using the turmoil library, which has been incredibly helpful (see the opbox-sim crate in the repo).

Show HN: Morph Reflexes – Multi-head classifiers for agent traces

The most common failures for production agents are behavioral: looping, reasoning leakage, user frustration, and more. Using a frontier model like GPT or Sonnet to judge every turn is too expensive and slow to run at scale.<p>To solve this, we built Reflexes: semantic signals from agent traces, served fast and cheap over API. Built on custom kernels and a custom inference engine forked from vLLM.<p>Under the hood, it is a small LLM architected around multi-head inference. Small models need to be trained for specific tasks, but running 50 separate small models on the same input for 50 tasks makes no sense.<p>How it works: We use a modern LLM with hybrid attention and remove the decode step. We built an inference engine that lets prefill compute be 99% reused from reflex to reflex, similar in spirit to older 2019-era BERT/HYDRA and older multiple-head techniques. we built the inference engine to reuse the KV/cache across inputs and compute across all reflexes. One shared backbone reads the trace once, then many heads classify different signals. Our inference engine reuses the same KV/cache and compute across all reflexes, giving us sub-30ms inference with less than 0.1% overhead for each additional reflex.<p>We took the same high-level idea and did the hard work to make it work with a modern architecture and attention. On it, we can run inference in under 30ms and serve the full request in under 90ms. If you run 4 reflexes or 100, the extra overhead is less than 2ms.<p>Why does optimizing this matter?<p>If you’re even a medium-sized startup, you’re dealing with tens of thousands of agent runs and millions of turns. If you want to track things like user frustration rates over time, frontier LLM-as-judge does not scale.<p>I built a similar stack at Tesla. When ML engineers needed to sample data across petabytes for signals like `is_camera_obfuscated=true`, along with 200 other things, you need to 1) spin them up quickly 2) run at scale efficiently<p>What it is not: A dashboard. 99% of dashboards go unused. 100% API first and made for devs who want to use this to trigger their own stuff.<p>vibetrain a custom reflex in our dashboard, and/or then let it self improve in production: <a href="https://www.morphllm.com/dashboard/reflex">https://www.morphllm.com/dashboard/reflex</a><p>Docs: <a href="https://docs.morphllm.com/sdk/components/reflexes/index">https://docs.morphllm.com/sdk/components/reflexes/index</a><p>I’d love feedback from people running agents in prod: what sorts of things do you wish you could track over time across 100% of turns but cant right now?<p>TLDR: semantic signals from agent traces, super fast, cheap via API

Show HN: CLI that helps AI agents avoid vulnerable dependencies

deptrust is a CLI that checks package versions for known vulnerabilities across npm, PyPI, crates.io, Go modules, RubyGems, NuGet, Maven, Packagist, pub.dev, CocoaPods, Hex.pm, Hackage, GitHub Actions, and more.<p>It runs locally as a CLI and as an MCP server. It calls public package registry and OSV APIs directly; there is no hosted deptrust service.<p>I built this because AI coding agents kept suggesting outdated or vulnerable package versions. I kept having to manually tell tools like Claude and Codex to use newer, safer versions.<p>deptrust gives the agent a quick way to verify whether a dependency version has known vulnerabilities before it installs or recommends it.<p>You can install it with:<p>1. pnpx @clidey/deptrust@latest install<p>2. brew install clidey/tap/deptrust<p>3. Or directly with go: go install github.com/clidey/deptrust/cmd/deptrust@latest

Show HN: Classify mechanical faults using Contrastive Language-Audio Pretraining

Show HN: Classify mechanical faults using Contrastive Language-Audio Pretraining

Show HN: A statically typed, cross-platform, easily bootstrappable build system

Show HN: A statically typed, cross-platform, easily bootstrappable build system

Show HN: I measured the half-life of 41,301 Show HN launches. It's 7 hours

I scraped every Show HN from the last 12 months (41,301 posts) plus the full comment tree of every launch with 10+ comments, ~100k comment timestamps, all from the Algolia HN API.<p>The median launch gets 2 points and 0 comments. For launches that do get traction, half the comments they'll ever get arrive within 7.2 hours and 90% within 26, and the top decile decays on the same clock as everyone else.<p>Vote timestamps aren't public, so comment timing is the attention proxy; caveats are in the post. Everything reproduces from the repo with one command (<a href="https://github.com/jonnonz1/hn-attention-cliff" rel="nofollow">https://github.com/jonnonz1/hn-attention-cliff</a>), and every number in the post maps to a named function. Keen to hear where the methodology falls short

Show HN: Mcpsnoop – Wireshark for MCP (transparent proxy and live TUI)

Show HN: Mcpsnoop – Wireshark for MCP (transparent proxy and live TUI)

Show HN: Mcpsnoop – Wireshark for MCP (transparent proxy and live TUI)

Show HN: Inkwell – An RSS reader for e-ink devices

Show HN: ctx – Search the coding agent history already on your machine

Coding agents don't have long-term memory.<p>But you do have months of full-fidelity agent transcripts stored on your machine.<p>A simple solution that goes a long way: ingest those transcripts and logs into a structured SQLite database, then search them with ranked text match. Everything is fully local and doesn't require anything fancy like a graph database or hosted memory service.<p>This is the idea behind ctx, a Rust CLI that handles the ingestion and searching.<p>We give our agents a skill that tells them to reference past sessions before working in an area. Usually we do this through an "Agent History Research Subagent" whose job is just to prepare a short brief covering any relevant history before the task begins.<p>A real example: sometimes our test suite runs would fail because disk was full on the runner. The correct approach was to run the cleanup runbook, but the root cause of the failure was not clear to the agents, so they would think it was a test regression and go down the wrong rabbit hole debugging. When the agent searched history, it realized this failure had been encountered before and found the right workaround immediately. That got the agent onto the right cleanup path, and later we improved the log output so the same failure would be clearer next time. It's a boring story, but it's real agent productivity.<p>Another nice use case is quickly generating session transcripts for sharing. You can exclude the noisy intermediate messages, so the transcript shows the important parts of the session more cleanly. Try attaching a session transcript to your next PR so your teammate and their agent can review the provenance and prompting behind the change.<p>If you're up for an additional challenge, ask your agent to "exhaustively review all agent history in this repo and find where the SDLC is struggling or isn't agent-native". Using past sessions to recursively improve the agentic SDLC is a loop that we're using a lot today.<p>If you try it out, please let us know what you think!

Show HN: ctx – Search the coding agent history already on your machine

Coding agents don't have long-term memory.<p>But you do have months of full-fidelity agent transcripts stored on your machine.<p>A simple solution that goes a long way: ingest those transcripts and logs into a structured SQLite database, then search them with ranked text match. Everything is fully local and doesn't require anything fancy like a graph database or hosted memory service.<p>This is the idea behind ctx, a Rust CLI that handles the ingestion and searching.<p>We give our agents a skill that tells them to reference past sessions before working in an area. Usually we do this through an "Agent History Research Subagent" whose job is just to prepare a short brief covering any relevant history before the task begins.<p>A real example: sometimes our test suite runs would fail because disk was full on the runner. The correct approach was to run the cleanup runbook, but the root cause of the failure was not clear to the agents, so they would think it was a test regression and go down the wrong rabbit hole debugging. When the agent searched history, it realized this failure had been encountered before and found the right workaround immediately. That got the agent onto the right cleanup path, and later we improved the log output so the same failure would be clearer next time. It's a boring story, but it's real agent productivity.<p>Another nice use case is quickly generating session transcripts for sharing. You can exclude the noisy intermediate messages, so the transcript shows the important parts of the session more cleanly. Try attaching a session transcript to your next PR so your teammate and their agent can review the provenance and prompting behind the change.<p>If you're up for an additional challenge, ask your agent to "exhaustively review all agent history in this repo and find where the SDLC is struggling or isn't agent-native". Using past sessions to recursively improve the agentic SDLC is a loop that we're using a lot today.<p>If you try it out, please let us know what you think!