Show stories

I built a CLI tool in Go that extracts structured data (JSON, CSV, Parquet) from messy PDFs and HTML pages.

The core idea: LLMs are great at understanding structure but wasteful for bulk data extraction. So smelt uses a two-pass architecture:

1. A fast Go capture layer parses the document and detects table-like regions 2. Those regions (not the whole document) get sent to Claude for schema inference — column names, types, nesting 3. The Go layer then does deterministic extraction using the inferred schema

This means the LLM is never in the hot path of actual data processing. It figures out "what is this data?" once, and then Go handles the "extract 10,000 rows" part efficiently.

Usage is simple:

  smelt invoice.pdf --format json
  smelt https://example.com/pricing --format csv
  smelt report.pdf --schema   # just show the inferred structure

Still early (no OCR yet, HTML is limited to <table> elements), but it handles the common cases well. Would love feedback on the architecture — especially from anyone who's dealt with PDF table extraction at scale.

When developers apply for jobs they usually send a portfolio link, GitHub, or resume.

But the process is a complete black box.

You never know:

• if the recruiter opened your resume • which repositories they checked • what projects caught their attention

So I built recruiter analytics for developer portfolios.

It tracks:

• profile views • repository clicks • resume open rate • viewer location insights • company type viewing the profile

The goal is to give developers a feedback loop similar to product analytics.

Instead of guessing what recruiters value, you can see which projects or skills actually get attention.

I wrote a technical breakdown of how the tracking works and the reasoning behind the design here:

Curious to hear what the HN community thinks about adding analytics to developer portfolios.

I've been building a modern Ultima Online server emulator from scratch. It's not feature-complete (no combat, no skills yet), but the foundation is solid and I wanted to share it early.

What it does today: - Full packet layer for the classic UO client (login, movement, items, mobiles) - Lua scripting for item behaviors (double-click a potion, open a door — all defined in Lua, no C# recompile) - Spatial world partitioned into sectors with delta sync (only sends packets for new sectors when crossing boundaries) - Snapshot-based persistence with MessagePack - Source generators for automatic DI wiring, packet handler registration, and Lua module exposure - NativeAOT support — the server compiles to a single native binary - Embedded HTTP admin API + React management UI - Auto-generated doors from map statics (same algorithm as ModernUO/RunUO)

Tech stack: .NET 10, NativeAOT, NLua, MessagePack, DryIoc, Kestrel

What's missing: Combat, skills, weather integration, NPC AI. This is still early — the focus so far has been on getting the architecture right so adding those systems doesn't require rewiring everything.

Why not just use ModernUO/RunUO? Those are mature and battle-tested. I started this because I wanted to rethink the architecture from scratch: strict network/domain separation, event-driven game loop, no inheritance-heavy item hierarchies, and Lua for rapid iteration on game logic without recompiling.

GitHub: https://github.com/moongate-community/moongatev2

The article introduces the TanStack Starter Kit, a comprehensive collection of tools and technologies designed to streamline the development of modern web applications. It highlights the key features, benefits, and the overall purpose of the starter kit.

Most CLI players have very rudimentary visualizations, so I focused on creating a "Quantum Spectrum Analyzer"—a high-frame-rate, physics-driven rainbow visualizer that uses gravity-based peak falling and mirrored symmetry.

Under the hood, it manages a pool of ffplay instances and uses OS-level process suspension (via ctypes on Windows and signal on POSIX) to provide an "instant-off" pause experience without cutting the audio buffer mid-stream.

Check it out here: https://github.com/iamekabir-web/Nirvana

Zero dependencies. No external databases. Single binary. Just deploy and go. I needed something that would allow for real-time monitoring, and installation is as simple as dropping a single file and running it. That's exactly what Kula is. Kula is the Polish word for "ball," as in "crystal ball." The project is in constant development, but I'm already using it on multiple servers in production. It still has some rough edges and needs to mature, but I wanted to share it with the world now—perhaps someone else will find it useful and be willing to help me develop it by testing or providing feedback. Cheers! Github: https://github.com/c0m4r/kula

This is a game I wish I had as a kid learning programming. The concept of it is fairly similar to other coding games like Screeps, but instead of a complex world with intricate mechanics, Yare is a lot more minimal and approachable with quick 1v1 <3 min matches.

It's purely a passion project with no monetization aspirations. And it's open source: https://github.com/riesvile/yare

The first version 'launched' several years ago and I got some good feedback here: https://news.ycombinator.com/item?id=27365961 that I iterated on.

The latest overhaul is a result of simplifying everything while still keeping the skill ceiling high. And at least the LLMs seem to struggle with this challenge for now (I run a small tournament between major models - results and details here: https://yare.io/ai-arena

I'd love to hear your thoughts

I got tired of sharing AI demos with terminal screenshots or screen recordings.

Claude Code already stores full session transcripts locally as JSONL files. Those logs contain everything: prompts, tool calls, thinking blocks, and timestamps.

I built a small CLI tool that converts those logs into an interactive HTML replay.

You can step through the session, jump through the timeline, expand tool calls, and inspect the full conversation.

The output is a single self-contained HTML file — no dependencies. You can email it, host it anywhere, embed it in a blog post, and it works on mobile.

Repo: https://github.com/es617/claude-replay

Example replay: https://es617.github.io/assets/demos/peripheral-uart-demo.ht...

Homebrew engine https://github.com/willtobyte/carimbo

Single Rust binary (~3 MB) that reads the OS accessibility tree and gives every UI element a REST endpoint. Click buttons, type text, toggle checkboxes — all via JSON. Works as an MCP server too, so Claude/Cursor/Windsurf can control any desktop app out of the box.

Windows + Linux + macOS. MIT licensed.

I built a browser-based port of fogleman/primitive — a Go CLI tool that approximates images using primitive shapes (triangles, ellipses, beziers, etc.) via a hill-climbing algorithm. The original tool requires building from source and running from the terminal, which isn't exactly accessible. I compiled the core logic to WebAssembly so anyone can drop an image and watch it get reconstructed shape by shape, entirely client-side with no server involved.

Demo: https://primitive-playground.taiseiue.jp/ Source: https://github.com/taiseiue/primitive-playground

Curious if anyone has ideas for shapes or features worth adding.

I built µJS because I wanted AJAX navigation without the verbosity of HTMX or the overhead of Turbo.

It intercepts links and form submissions, fetches pages via AJAX, and swaps fragments of the DOM. Single <script> tag, one call to `mu.init()`. No build step, no dependencies.

Key features: patch mode (update multiple fragments in one request), SSE support, DOM morphing via idiomorph, View Transitions, prefetch on hover, polling, and full HTTP verb support on any element.

At ~5KB gzipped, it's smaller than HTMX (16KB) and Turbo (25KB), and works with any backend: PHP, Python, Go, Ruby, whatever.

Playground: https://mujs.org/playground

Comparison with HTMX and Turbo: https://mujs.org/comparison

About the project creation, why and when: https://mujs.org/about

GitHub: https://github.com/Digicreon/muJS

Happy to discuss the project.

Hi HN,

I’m part of the team building Sniphi.

Sniphi is a modular digital nose that uses gas sensors and machine-learning models to convert volatile organic compound (VOC) data into a machine-readable signal that can be integrated into existing QA, monitoring, or automation systems. The system is currently in an R&D phase, but already exists as working hardware and software and is being tested in real environments.

The project grew out of earlier collaborations with university researchers on gas sensors and odor classification. What we kept running into was a gap between promising lab results and systems that could actually be deployed, integrated, and maintained in real production environments.

One of our core goals was to avoid building a single-purpose device. The same hardware and software stack can be trained for different use cases by changing the training data and models, rather than the physical setup. In that sense, we think of it as a “universal” electronic nose: one platform, multiple smell-based tasks.

Some design principles we optimized for:

- Composable architecture: sensor ingestion, ML inference, and analytics are decoupled and exposed via APIs/events

- Deployment-first thinking: designed for rollout in factories and warehouses, not just controlled lab setups

- Cloud-backed operations: model management, monitoring, updates run on Azure, which makes it easier to integrate with existing industrial IT setups

- Trainable across use cases: the same platform can be retrained for different classification or monitoring tasks without redesigning the hardware

One public demo we show is classifying different coffee aromas, but that’s just a convenient example. In practice, we’re exploring use cases such as:

- Quality control and process monitoring

- Early detection of contamination or spoilage

- Continuous monitoring in large storage environments (e.g. detecting parasite-related grain contamination in warehouses)

Because this is a hardware system, there’s no simple way to try it over the internet. To make it concrete, we’ve shared:

- A short end-to-end demo video showing the system in action (YouTube)

- A technical overview of the architecture and deployment model: https://sniphi.com/

At this stage, we’re especially interested in feedback and conversations with people who:

- Have deployed physical sensors at scale

- Have run into problems that smell data might help with

- Are curious about piloting or testing something like this in practice

We’re not fundraising here. We’re mainly trying to learn where this kind of sensing is genuinely useful and where it isn’t.

Happy to answer technical questions.

The article describes mb-cli, an open-source command-line interface (CLI) tool for interacting with the Mastodon decentralized social network. The tool provides a simple and intuitive way to manage Mastodon accounts, post updates, and interact with the Fediverse from the terminal.

We built an ant colony simulation as an internal hiring challenge at Moment and decided to open it up publicly.

You write a program in a custom assembly-like (we call it ant-ssembly) instruction set that controls 200 ants. Each ant can sense nearby cells (food, pheromones, home, other ants) but has no global view. The only coordination mechanism is pheromone trails, which ants can emit and sense them, but that's it. Your program runs identically on every ant.

The goal is to collect the highest percentage of food across a set of maps. Different map layouts (clustered food, scattered, obstacles) reward very different strategies. The leaderboard is live.

Grand prize is a trip to Maui for two paid for by Moment. Challenge closes March 12.

Curious what strategies people discover. We've seen some surprisingly clever emergent behavior internally.

Netrek is a multiplayer space battle game from 1988–89, widely considered the first Internet team game. It predates commercial online gaming by years, ran passionate leagues for decades, and is still technically alive — but getting a server up has always required real effort, and there’s been no easy way to just play it in a browser. NeoNetrek is my attempt to change that: Server: Based on the original vanilla Netrek C server, modernized with simpler configuration and containerized for one-command cloud deployment. There are ready-made templates for Fly.io and Railway, and public servers already running in LAX, IAD, NRT, and LHR. Anyone can self-host using the deploy templates in the GitHub org. Client: A new 3D browser-based client — no downloads, no plugins, connects via WebSocket. I built it starting from Andrew Sillers’ html5-netrek (github.com/apsillers/html5-netrek) as a foundation and took it in a new direction with 3D rendering. Site: neonetrek.com covers lore, factions, ship classes, ranks, and an Academy to ease the notoriously steep learning curve. A significant portion of the code and content was developed with Claude as a coding partner, which felt fitting for a project about preserving internet history. GitHub org: https://github.com/neonetrek Play now: https://neonetrek.com

The article provides an overview of the Seafloor project, which aims to map the entire seafloor using various technologies and data sources. The project aims to create a comprehensive and publicly available dataset to improve our understanding of the world's oceans and their ecosystems.

Hi HN!

I'm the author of an Elixir Agent Framework called Jido. We reached our 2.0 release this week, shipping a production-hardened framework to build, manage and run Agents on the BEAM.

Jido now supports a host of Agentic features, including:

- Tool Calling and Agent Skills - Comprehensive multi-agent support across distributed BEAM processes with Supervision - Multiple reasoning strategies including ReAct, Chain of Thought, Tree of Thought, and more - Advanced workflow capabilities - Durability through a robust Storage and Persistence layer - Agentic Memory - MCP and Sensors to interface with external services - Deep observability and debugging capabilities, including full stack OTel

I know Agent Frameworks can be considered a bit stale, but there hasn't been a major release of a framework on the BEAM. With a growing realization that the architecture of the BEAM is a good match for Agentic workloads, the time was right to make the announcement.

My background is enterprise engineering, distributed systems and Open Source. We've got a strong and growing community of builders committed to the Jido ecosystem. We're looking forward to what gets built on top of Jido!

Come build agents with us!

LLMs are better at being the "mouth" than the "brain" and I can prove it mathematically. I built a deterministic graph engine that offloads reasoning from the LLM. It reduces token usage by 89% and makes a tiny 0.8B model trace enterprise execution paths flawlessly. Here is the white paper and the reproducible benchmark.

Title: Show HN: PageAgent, A GUI agent that lives inside your web app

Hi HN,

I'm building PageAgent, an open-source (MIT) library that embeds an AI agent directly into your frontend.

I built this because I believe there's a massive design space for deploying general agents natively inside the web apps we already use, rather than treating the web merely as a dumb target for isolated bots.

Currently, most AI agents operate from external clients or server-side programs, effectively leaving web development out of the AI ecosystem. I'm experimenting with an "inside-out" paradigm instead. By dropping the library into a page, you get a client-side agent that interacts natively with the live DOM tree and inherits the user's active session out of the box, which works perfectly for SPAs.

To handle cross-page tasks, I built an optional browser extension that acts as a "bridge". This allows the web-page agent to control the entire browser with explicit user authorization. Instead of a desktop app controlling your browser, your web app is empowered to act as a general agent that can navigate the broader web.

I'd love to start a conversation about the viability of this architecture, and what you all think about the future of in-app general agents. Happy to answer any questions!

The article describes a transforming drone called Mercury, which can switch between a fixed-wing and a multirotor configuration. The drone is designed to combine the advantages of both fixed-wing and multirotor platforms, enabling efficient long-range flight and precise maneuvering.

A fun weekend project: https://www.modembin.com

It's a pastebin, except text/files are encoded into .wav files using real FSK modem audio. Image sharing is supported via Slow-Scan Television (SSTV), a method of transmitting images as FM audio originally used by ham radio operators.

Everything runs in the browser with zero audio libraries and the encoding is vanilla TypeScript sine wave math: phase-continuous FSK with proper 8-N-1 framing, fractional bit accumulation for non-integer sample rates, and a quadrature FM discriminator on the decode side (no FFT windowing or Goertzel), The only dependency is lz-string for URL sharing compression.

It supports Bell 103 (300 baud), Bell 202 (1200 baud), V.21, RTTY/Baudot, Caller ID (Bellcore MDMF), DTMF, Blue Box MF tones, and SSTV image encoding. There's also a chat mode where messages are transmitted as actual Bell 103 audio over WebSocket... or use the acoustic mode for speaker-to-mic coupling for in-room local chat.

I built sqry, a local code search tool that works at the semantic level rather than the text level.

The motivation: ripgrep is great for finding strings, but it can't tell you "who calls this function", "what does this function call", or "find all public async functions that return Result". Those questions require understanding code structure, not just matching patterns.

sqry parses your code into an AST using tree-sitter, builds a unified call/ import/dependency graph, and lets you query it:

  sqry query "callers:authenticate"
  sqry query "kind:function AND visibility:public AND lang:rust"
  sqry graph trace-path main handle_request
  sqry cycles
  sqry ask "find all error handling functions"

Some things that might be interesting to HN:

- 35 language plugins via tree-sitter (C, Rust, Go, Python, TypeScript, Java, SQL, Terraform, and more) - Cross-language edge detection: FFI linking (Rust↔C/C++), HTTP route matching (JS/TS↔Python/Java/Go) - 33-tool MCP server so AI assistants get exact call graph data instead of relying on embedding similarity - Arena-based graph with CSR storage; indexed queries run ~4ms warm - Cycle detection, dead code analysis, semantic diff between git refs

It's MIT-licensed and builds from source with Rust 1.90+. Fair warning: full build takes ~20 GB disk because 35 tree-sitter grammars compile from source.

Repo: https://github.com/verivusai-labs/sqry Docs: https://sqry.dev

Happy to answer questions about the architecture, the NL translation approach, or the cross-language detection.

I've been building go-tui (https://go-tui.dev), a terminal UI framework for Go inspired by the templ framework for the web (https://templ.guide/). The syntax should be familiar to templ users and is quite different from other terminal frameworks like bubbletea. Instead of imperative widget manipulation or bubbletea's elm architecture, you write HTML-like syntax and Tailwind-style classes that can intermingle with regular Go code in a new .gsx filetype. Then you compile these files to type-safe Go using `tui generate`. At runtime there's a flexbox layout engine based on yoga that handles positioning and a double-buffered renderer that diffs output to minimize terminal writes.

Here are some other features in the framework:

- It supports reactive state with State[T]. You change a value and the framework redraws for you. You can also forego reactivity and simply use pure components if you would like.

- You can render out a single frame to the terminal scrollback if you don't care about UIs and just want to place a box, table, or other styled component into your stdout. It's super handy and avoids the headache of dealing with the ansi escape sequences directly.

- It supports an inline mode that lets you embed an interactive widget in your shell session instead of taking over the full screen. With it you can build things like custom streaming chat interfaces directly in the terminal.

- I built full editor support for the new filetype. I published a VS Code and Open-VSX extension with completion, hover, and go-to-definition. Just search for "go-tui" in the marketplace to find them. The repo also includes a tree-sitter grammar for Neovim/Helix, and an LSP that proxies Go features through gopls so the files are easy to work with.

There are roughly 20 examples in the repo covering everything from basic components to a dashboard with live metrics and sparklines. I also built an example wrapper for claude code if you wanted to build your own AI chat interface.

Docs & guides: https://go-tui.dev

Repo: https://github.com/grindlemire/go-tui

I'd love feedback on the project!

I built Poppy as a side project to help people keep in touch more intentionally. Would love feedback on onboarding, reminders, and overall UX. Happy to answer questions.

I built Mystery Maker AI as a side project. It's a web-based party game that lets you team up with friends (like Jackbox) to interrogate 4 suspects and solve a murder mystery.

There are 4 mysteries to solve, including some with goofy parodies of presidents / billionaires, and some that you can fork and replace the characters with AI clones of your friends for a good time. As the name implies, you can also create your own mysteries from scratch if that's your thing!

It's free to demo, and the full game costs $15. Unfortunately, sign in is required for the demo, to keep my AI costs in check.

Hope you enjoy it as much as my friends and family did. It's a perfect excuse to plan a get-together and try something new!

The article discusses a PostgreSQL extension called 'pg_sorted_heap' that provides an alternative to the standard B-tree index. It offers improved performance for certain types of queries by storing data in a heap structure sorted by the indexed column.

hacked together over a few nights I found it surprisingly capable, let me know your thoughts if any.

This is an ncdu clone written in Rust that I figured others might find useful! The main things that differentiate it from ncdu are: - It's very fast. In my benchmarks it's often twice as fast. - It allows you to send files to trash rather than permanently delete.

Please try it out and lmk if I can improve on anything!