Show stories

I've been talking to founders building AI agents across fintech, devtools, and productivity – and almost none of them have any real security layer. Their agents read emails, call APIs, execute code, and write to databases with essentially no guardrails beyond "we trust the LLM."

So I built AgentArmor: an open-source framework that wraps any agentic architecture with 8 independent security layers, each targeting a distinct attack surface in the agent's data flow.

The 8 layers: L1 – Ingestion: prompt injection + jailbreak detection (20+ patterns, DAN, extraction attempts, Unicode steganography) L2 – Storage: AES-256-GCM encryption at rest + BLAKE3 integrity for vector DBs L3 – Context: instruction-data separation (like parameterized SQL, but for LLM context), canary tokens, prompt hardening L4 – Planning: action risk scoring (READ=1 → DELETE=7 → EXECUTE=8 → ADMIN=10), chain depth limits, bulk operation detection L5 – Execution: network egress control, per-action rate limiting, human approval gates with conditional rules L6 – Output: PII redaction via Microsoft Presidio + regex fallback L7 – Inter-agent: HMAC-SHA256 mutual auth, trust scoring, delegation depth limits, timestamp-bound replay prevention L8 – Identity: agent-native identity, JIT permissions, short-lived credentials

I tested it against all 10 OWASP ASI (Agentic Security Integrity) risks from the December 2025 spec. The red team suite is included in the repo.

Works as: (a) a Python library you wrap around tool calls, (b) a FastAPI proxy server for framework-agnostic deployment, or (c) a CLI for scanning prompts in CI.

Integrations included for: LangChain, OpenAI Agents SDK, MCP servers.

I ran it live with a local Ollama agent (qwen2:7b) – you can watch it block a `database.delete` at L8 (permission check), redact PII from file content at L6, and kill a prompt injection at L1 before it ever reaches the model.

GitHub: https://github.com/Agastya910/agentarmor PyPI: pip install agentarmor-core

Would love feedback, especially from people who have actually built production agents and hit security issues I haven't thought of.

TAGS: security, python, llm, ai, agents

I know, it's a very first-world problem. But in my house, we have a hard time deciding what to watch. Too many options!

So I made this to recreate Cable TV for YouTube. I made it so it runs in the browser. Quickly import your subscriptions in the browser via a bookmarklet. No accounts, no sign-ins. Just quickly import your data locally.

We built an open-source proxy that sits between coding agents (Claude Code, OpenClaw, etc.) and the LLM, compressing tool outputs before they enter the context window.

Demo: https://www.youtube.com/watch?v=-vFZ6MPrwjw#t=9s.

Motivation: Agents are terrible at managing context. A single file read or grep can dump thousands of tokens into the window, most of it noise. This isn't just expensive — it actively degrades quality. Long-context benchmarks consistently show steep accuracy drops as context grows (OpenAI's GPT-5.4 eval goes from 97.2% at 32k to 36.6% at 1M https://openai.com/index/introducing-gpt-5-4/).

Our solution uses small language models (SLMs): we look at model internals and train classifiers to detect which parts of the context carry the most signal. When a tool returns output, we compress it conditioned on the intent of the tool call—so if the agent called grep looking for error handling patterns, the SLM keeps the relevant matches and strips the rest.

If the model later needs something we removed, it calls expand() to fetch the original output. We also do background compaction at 85% window capacity and lazy-load tool descriptions so the model only sees tools relevant to the current step.

The proxy also gives you spending caps, a dashboard for tracking running and past sessions, and Slack pings when an agent is sitting there waiting on you.

Repo is here: https://github.com/Compresr-ai/Context-Gateway. You can try it with:

  curl -fsSL https://compresr.ai/api/install | sh

Hi this is a work in progress but it works to determine supplement efficacy for 500 conditions at the moment.

Things you can do:

- search for a condition -> find which supplements are effective -> see which studies indicate they are effective -> read individual study summaries

- search for a supplement -> see effectiveness table, dosing, safety, dietary sources, mechanisms of action (+ browse all original sources)

let me know what you think

I built this because I wanted to know what people in Japan were listening to the year I was born. That question spiraled: how does a hit in Rome compare to what was charting in Lagos the same year? How did sonic flavors propagate as streaming made musical influence travel faster than ever? 88mph is a playable map of music history: 230 charts across 20 countries, spanning 8 decades (1940–2025). Every song is playable via YouTube or Spotify. It's open source and I'd love help expanding it — there's a link to contribute charts for new countries and years. The goal is to crowdsource a complete sonic atlas of the world.

I have been interested in neural nets since the 90's. I've done quite a bit of reading, but never gotten around to writing code. I used Gemini in place of Wikipedia to fill in the gaps of my knowledge. The coolest part of this was learning about dual numbers. You can see in early commits that I did not yet know about auto-diff; I was thinking I'd have to integrate a CAS library or something. Now, I'm off to play with TensorFlow.

I built Axe because I got tired of every AI tool trying to be a chatbot.

Most frameworks want a long-lived session with a massive context window doing everything at once. That's expensive, slow, and fragile. Good software is small, focused, and composable... AI agents should be too.

Axe treats LLM agents like Unix programs. Each agent is a TOML config with a focused job. Such as code reviewer, log analyzer, commit message writer. You can run them from the CLI, pipe data in, get results out. You can use pipes to chain them together. Or trigger from cron, git hooks, CI.

What Axe is:

- 12MB binary, two dependencies. no framework, no Python, no Docker (unless you want it)

- Stdin piping, something like `git diff | axe run reviewer` just works

- Sub-agent delegation. Where agents call other agents via tool use, depth-limited

- Persistent memory. If you want, agents can remember across runs without you managing state

- MCP support. Axe can connect any MCP server to your agents

- Built-in tools. Such as web_search and url_fetch out of the box

- Multi-provider. Bring what you love to use.. Anthropic, OpenAI, Ollama, or anything in models.dev format

- Path-sandboxed file ops. Keeps agents locked to a working directory

Written in Go. No daemon, no GUI.

What would you automate first?

svglib is a SVG file parser and renderer library for Windows. It uses Direct2D for GPU assisted rendering and XMLLite for XML parsing.

This is meant for Win32 applications and games to easily display SVG images.

I built vibe-budget because I kept burning tokens without knowing the cost upfront. You describe your project in plain English (or Spanish), and it detects the tasks involved, estimates token usage, and compares real-time prices across 85+ models via OpenRouter.

Example: vibe-budget plan ecommerce with stripe oauth and supabase

It detects 4 tasks, estimates ~497k tokens, and shows you the cheapest, best quality-price, and premium model options side by side.

It also has a scan command — point it at an existing codebase and it estimates how many tokens it would cost to refactor or extend it with AI.

No API key required. Prices are fetched live from OpenRouter with a 1-hour cache fallback.

npm install -g vibe-budget

Docs: https://gaboexe0.github.io/vibe-budget/ Repo: https://github.com/gaboexe0/vibe-budget

I work on AWS infrastructure (ex-Percona, Box, Dropbox, Pinterest). When OpenClaw blew up, I wanted to run it properly on AWS and was surprised by the default deployment story. The Lightsail blueprint shipped with 31 unpatched CVEs. The standard install guide uses three separate curl-pipe-sh patterns as root. Bitsight found 30,000+ exposed instances in two weeks. OpenClaw's own maintainer said "if you can't understand how to run a command line, this is far too dangerous."

So I built a Terraform module that replaces the defaults with what I'd consider production-grade:

* Cognito + ALB instead of a shared gateway token (per-user identity, MFA) * GPG-verified APT packages instead of curl|bash * systemd with ProtectHome=tmpfs and BindPaths sandboxing * Secrets Manager + KMS instead of plaintext API keys * EFS for persistence across instance replacement * CloudWatch logging with 365-day retention Bedrock is the default LLM provider so it works without any API keys. One terraform apply. Full security writeup: https://infrahouse.com/blog/2026-03-09-deploying-openclaw-on...

I'm sure I've missed things. What would you add or do differently for running an autonomous agent with shell access on a shared server?

I built kube-pilot — an autonomous AI agent that runs inside your Kubernetes cluster and does the full dev loop: writes code, builds containers, deploys services, verifies they're healthy, and closes the ticket. You file a GitHub issue, it does the rest.

What makes this different from AI coding tools: kube-pilot doesn't just generate code and hand it back to you. It lives inside the cluster with direct access to the entire dev stack — git, Tekton (CI/CD), Kaniko (container builds), ArgoCD (GitOps deployments), kubectl, Vault. Every tool call produces observable state that feeds into the next decision. The cluster isn't just where code runs — it's where the agent thinks.

The safety model: all persistent changes go through git, so everything is auditable and reversible. ArgoCD is the only thing that writes to the cluster. Secrets stay behind Vault — the agent creates ExternalSecret references, never touches raw credentials. Credentials are scrubbed before reaching the LLM.

Live demo: I filed GitHub issues asking it to build a 4-service office suite (auth, docs API, notification worker, API gateway). It built and deployed all of them autonomously. You can see the full agent loop — code, builds, deploys, verification, comments — on the closed issues:

- https://github.com/fbongiovanni29/clouddesk-auth-service/iss... - https://github.com/fbongiovanni29/clouddesk-docs-api/issues/... - https://github.com/fbongiovanni29/clouddesk-notifications-wo... - https://github.com/fbongiovanni29/clouddesk-web-gateway/issu...

One helm install gives you everything — the agent, Gitea (git + registry), Tekton, ArgoCD, Vault, External Secrets. No external dependencies.

Coming next: Slack and Jira integrations (receive tasks and post updates where your team already works), Prometheus metrics and Grafana dashboards for agent observability, and Alertmanager integration so firing alerts automatically become issues that kube-pilot investigates and fixes.

Early proof of concept. Rough edges. But it works.

We built OneCLI because AI agents are being given raw API keys. And it's going about as well as you'd expect. We figured the answer isn't "don't give agents access," it's "give them access without giving them secrets."

OneCLI is an open-source gateway that sits between your AI agents and the services they call. You store your real credentials once in OneCLI's encrypted vault, and give your agents placeholder keys. When an agent makes an HTTP call through the proxy, OneCLI matches the request by host/path, verifies the agent should have access, swaps the placeholder for the real credential, and forwards the request. The agent never touches the actual secret. It just uses CLI or MCP tools as normal.

Try it in one line: docker run --pull always -p 10254:10254 -p 10255:10255 -v onecli-data:/app/data ghcr.io/onecli/onecli

The proxy is written in Rust, the dashboard is Next.js, and secrets are AES-256-GCM encrypted at rest. Everything runs in a single Docker container with an embedded Postgres (PGlite), no external dependencies. Works with any agent framework (OpenClaw, NanoClaw, IronClaw, or anything that can set an HTTPS_PROXY).

We started with what felt most urgent: agents shouldn't be holding raw credentials. The next layer is access policies and audit, defining what each agent can call, logging everything, and requiring human approval before sensitive actions go through.

It's Apache-2.0 licensed. We'd love feedback on the approach, and we're especially curious how people are handling agent auth today.

GitHub: https://github.com/onecli/onecli Site: https://onecli.sh

We built rudel.ai after realizing we had no visibility into our own Claude Code sessions. We were using it daily but had no idea which sessions were efficient, why some got abandoned, or whether we were actually improving over time.

So we built an analytics layer for it. After connecting our own sessions, we ended up with a dataset of 1,573 real Claude Code sessions, 15M+ tokens, 270K+ interactions.

Some things we found that surprised us: - Skills were only being used in 4% of our sessions - 26% of sessions are abandoned, most within the first 60 seconds - Session success rate varies significantly by task type (documentation scores highest, refactoring lowest) - Error cascade patterns appear in the first 2 minutes and predict abandonment with reasonable accuracy - There is no meaningful benchmark for 'good' agentic session performance, we are building one.

The tool is free to use and fully open source, happy to answer questions about the data or how we built it.

I built Understudy because a lot of real work still spans native desktop apps, browser tabs, terminals, and chat tools. Most current agents live in only one of those surfaces.

Understudy is a local-first desktop agent runtime that can operate GUI apps, browsers, shell tools, files, and messaging in one session. The part I'm most interested in feedback on is teach-by-demonstration: you do a task once, the agent records screen video + semantic events, extracts the intent rather than coordinates, and turns it into a reusable skill.

Demo video: https://www.youtube.com/watch?v=3d5cRGnlb_0

In the demo I teach it: Google Image search -> download a photo -> remove background in Pixelmator Pro -> export -> send via Telegram. Then I ask it to do the same for Elon Musk. The replay isn't a brittle macro: the published skill stores intent steps, route options, and GUI hints only as a fallback. In this example it can also prefer faster routes when they are available instead of repeating every GUI step.

Current state: macOS only. Layers 1-2 are working today; Layers 3-4 are partial and still early.

    npm install -g @understudy-ai/understudy
    understudy wizard

Happy to answer questions about the architecture, teach-by-demonstration, or the limits of the current implementation.

I’ve been experimenting with infrastructure for multi-agent systems.

I built a small project called AgentLog.

The core idea is very simple, topics are just append-only JSONL files.

Agents publish events over HTTP and subscribe to streams using SSE.

The system is intentionally single-node and minimal for now.

Future ideas I’m exploring: - replayable agent workflows - tracing reasoning across agents - visualizing event timelines - distributed/federated agent logs

Curious if others building agent systems have run into similar needs.

Hey HN,

My cofounder and I have gotten tired of CC ignoring our markdown files so we spent 4 days and built a plugin that automatically steers CC based on our previous sessions. The problem is usually post plan-mode.

What we've tried:

Heavily use plan mode (works great)

CLAUDE.md, AGENTS.md, MEMORY.md

Local context folder (upkeep is a pain)

Cursor rules (for Cursor)

claude-mem (OSS) -> does session continuity, not steering

We use fusion search to find your CC steering corrections.

- user prompt embeddings + bm25

- correction embeddings + bm25

- time decay

- target query embeddings

- exclusions

- metadata hard filters (such as files)

The CC plugin:

- Automatically captures memories/corrections without you having to remind CC

- Automatically injects corrections without you having to remind CC to do it.

The plugin will merge, update, and distill your memories, and then inject the highest relevant ones after each of your own prompts.

We're not sure if we're alone in this. We're working on some benchmarks to see how effective context injection actually is in steering CC and we know we need to keep improving extraction, search, and add more integrations.

We're passionate about the real-time and personalized context layer for agents. Giving Agents a way to understand what you mean when you say "this" or "that". Bringing the context of your world, into a secure, structured, real-time layer all your agents can access.

Would appreciate feedback on how you guys get CC to actually follow your markdown files, understand your modus operandi, feedback on the plugin, or anything else about real-time memory and context.

- Ankur

Hey HN, I often wish I could go back to some year and listen to the radio as it played then, with songs that fit that time period.

But not every moment is the same, and humans turn to music for various purposes. Genres feel arbitrary and limiting, so I thought it would make more sense to create stations based on a specific vibe. Are you looking for something chill or intense? Alone or with friends? Is this a dinner party, a dance floor, or winding down afterhours?

So I built Anthrology as a way to navigate across time and vibes. I've been listening to it pretty much nonstop for a couple of days, and I hope you'll enjoy it too.

Songs are already playing by the time you tune to a year and vibe. You can tune to some other moment and come back, and the track will still be playing—but you'll have missed a little bit of the song, just like the radio!

And the radio is (more or less) deterministic, so we all hear the same tracks.

Tune in and enjoy!

The Mutate-public repository on GitHub contains an open-source implementation of a mutation testing framework. This tool helps developers assess the quality of their test suites by measuring how well they detect intentional code changes (mutations).

Debugging a crash can sometimes feel like a noir detective story: following faint clues, chasing red herrings, and eventually hitting the moment where the whole case finally makes sense. I leaned into that idea and built Fatal Core Dump, a small game where the investigation is real crash debugging.

The game gives you a Linux binary, its core dump, a source file, and some logs. You solve the mystery by debugging it.

The premise: an engineer dies when an airlock on an asteroid mining station opens unexpectedly. Your job is to determine whether it was a simple software bug or something more deliberate.

The investigation uses real debugging tools and techniques. You can use whatever debugging setup you prefer.

There’s also a spoiler-heavy blog post describing how the game was conceived and implemented, and the full code is available if you’re curious about how it works or want to experiment with the idea.

Blog post: https://www.robopenguins.com/core-dump-game/ Source: https://github.com/axlan/fatal_core_dump

If you enjoy debugging puzzles or low-level Linux tooling, I’d love to hear what you think.

Hi HN,

I'm a self-taught developer from Malawi, and I built DJX because I was tired of writing the same Django boilerplate over and over.

Django is powerful, but starting a new feature means manually creating models, views, templates, URLs, and wiring everything together. Rails solved this 20 years ago with scaffolding. Django deserves the same.

DJX brings convention over configuration to Django:

    pip install djx-cli                                                                                            
    djx new myblog && cd myblog                                                                                    
    djx scaffold Post title:string content:text published:boolean                                                  
    python manage.py migrate && python manage.py runserver                                                         
    # → http://127.0.0.1:8000/posts/ — full CRUD. Done.                                                            
                                                                                                                   

Other commands: - `djx routes` — see all URL routes (Django doesn't have this built-in) - `djx destroy scaffold Post` — clean removal of generated code - `djx add django-crispy-forms` — install and auto-add to INSTALLED_APPS - `djx model`, `djx controller` — generate pieces individually

It follows Rails conventions: pluralized app names, RESTful URLs, automatic timestamps, and sensible defaults.

I built this because I wanted Django development to feel as fast as Rails. It's early stage, but it's already saving me hours on every project.

PyPI: https://pypi.org/project/djx-cli/ GitHub: https://github.com/RedsonNgwira/djx-cli

Would love your feedback and contributions. What other Rails-like features would make Django development faster?

Hi HN, I forked chromium and built agent-browser-protocol (ABP) after noticing that most browser-agent failures aren’t really about the model misunderstanding the page. Instead, the problem is that the model is reasoning from a stale state.

ABP is designed to keep the acting agent synchronized with the browser at every step. After each action (click, type, etc), it freezes JavaScript execution and rendering, then captures the resulting state. It also compiles the notable events that occurred during that action loop, such as navigation, file pickers, permission prompts, alerts, and downloads, and sends that along with a screenshot of the frozen page state back to the agent.

The result is that browser interaction starts to feel more like a multimodal chat loop. The agent takes an action, gets back a fresh visual state and a structured summary of what happened, then decides what to do next from there. That fits much better with how LLMs already work.

A few common browser-use failures ABP helps eliminate: * A modal appears after the last Playwright screenshot and blocks the input the agent was about to use * Dynamic filters cause the page to reflow between steps * An autocomplete dropdown opens and covers the element the agent intended to click * alert() / confirm() interrupts the flow * Downloads are triggered, but the agent has no reliable way to know when they’ve completed

As proof, ABP with opus 4.6 as the driver scores 90.5% on the Online Mind2Web benchmark. I think modern LLMs already understand websites, they just need a better tool to interact with them. Happy to answer questions about the architecture, forking chrome or anything else in the comments below.

Try it out: `claude mcp add browser -- npx -y agent-browser-protocol --mcp` (Codex/OpenCode instructions in the docs)

Demo video: https://www.loom.com/share/387f6349196f417d8b4b16a5452c3369

I built a macOS voice dictation app where zero bytes of audio ever leave your machine.

EdgeWhisper runs Voxtral Mini 4B Realtime (Mistral AI, Apache 2.0) locally on Apple Silicon via the MLX framework. Hold a key, speak, release — text appears at your cursor in whatever app has focus.

Architecture: - Native Swift (SwiftUI + AppKit). No Electron. - Voxtral 4B inference via MLX on the Neural Engine. ~3GB model, runs in ~2GB RAM on M1+. - Dual text injection: AXUIElement (preserves undo stack) with NSPasteboard+CGEvent fallback. - 6-stage post-processing pipeline: filler removal → dictionary → snippets → punctuation → capitalization → formatting. - Sliding window KV cache for unlimited streaming without latency degradation. - Configurable transcription delay (240ms–2.4s). Sweet spot at 480ms.

What it does well: - Works in 20+ terminals/IDEs (VS Code, Xcode, iTerm2, Warp, JetBrains). Most dictation tools break in terminals — we detect them and switch injection strategy. - Removes filler words automatically ("um", "uh", "like"). - 13 languages with auto-detection. - Personal dictionary + snippet expansion with variable support ({{date}}, {{clipboard}}). - Works fully offline after model download. No accounts, no telemetry, no analytics.

What it doesn't do (yet): - No file/meeting transcription (coming) - No translation (coming) - No Linux/Windows (macOS only, Apple Silicon required)

Pricing: Free tier (5 min/day, no account needed). Pro at $7.99/mo or $79.99/yr.

I'd love feedback on: 1. Would local LLM post-processing (e.g., Phi-4-mini via MLX) for grammar/tone be worth the extra ~1GB RAM? 2. For developers using voice→code workflows: what context would you want passed to your editor? 3. Anyone else building on Voxtral Realtime? Curious about your experience with the causal audio encoder.

Hi HN,

I’m the creator of Sapphire, a lightweight programming language written in C++ designed to hit the "sweet spot" between high-level ease of use and low-level performance. I’ve just released version 1.0.7, which is our final push before the 1.1 LTS (Long Term Support) version.

The goal of Sapphire is simple: Zero friction. No complex installers, no pip install, no npm headaches. Just a single 12MB binary that gives you everything you need to build UI tools, network apps, or performance-critical scripts out of the box.

What’s new in 1.0.7: Vector Math: Added native support for 2D and 3D vectors, making it much easier to build games or simulations (check the Raycaster link below).

Syntax Fluidity: We’ve relaxed the syntax rules to make coding feel more natural and less "rigid" without sacrificing the speed of the VM.

LTS Preparation: Focus on stability and bug fixes as we approach our first Long Term Support milestone.

Key Features: Immediate Mode UI: Built-in UI engine (SapphireUI) using SFML for rendering. You can create windows and buttons instantly without external DLLs.

High-Performance VM: Uses Direct Threading (Computed GOTOs). It handles 100 million iterations in ~9 seconds on a standard consumer CPU.

No Imports Needed: Native support for Terminal colors, JSON parsing, HTTP functions, and System communication is baked into the core.

Portable: Download the .exe, add to PATH, and you're ready. The VM + UI + Networking + JSON is all in one 12MB file.

Try it out: Repo: github.com/foxzyt/Sapphire

Raycaster: github.com/foxzyt/SapphireRaycaster

Got real tired of juggling five tabs and a terminal to compress different file types. So I built something that handles them ALL in one place.

Supports 50+ input formats. If something is compressible it will handle it. Upload a file, it figures out what it is, compresses it, hands it back. Ephemeral storage for 2 hours. Format conversion works pretty well too.

The part I'm most happy with is the detection layer. For binary formats, magic bytes get you most of the way there. For text-based (JS, CSS, JSON, XML, etc) I run a small ML classifier on the content itself to identify the format and route it to the right compression pipeline without asking the user to specify.

REST API if you want to plug it into a pipeline. Webhooks for async jobs, bring-your-own-storage for S3/GCS/Azure/whatever. Batch jobs work well.

No signup required, free tier with very generous monthly quota. Feedback, edge cases that break the detector, feature requests - all welcome.

I'm sharing a userscript for for those who read the HN comments section a lot:

1. Updates comments without reloading the page — instantly see new ones as they appear.

2. Cleaner comment topline for less distraction — shows controls only when you hover over the topline.

There is a preview gif of how it looks in the README.

Hi HN, I’m a chemical engineer and I manage logistics at a refinery down in Texas. Whenever I try to explain downstream operations to people outside the industry (including my kids), I usually get blank stares. I wanted to build something that visualizes the concepts and chemistry of a plant without completely dumbing down the science, so I put together this 5-minute browser game.

Here's a simple runthrough: https://www.youtube.com/watch?v=is-moBz6upU. I pushed to get through a full product pathway to show the V-804 replay.

I am not a software developer by trade, so I relied heavily on LLMs (Claude, Copilot, Gemini) to help write the code. What started as a simple concept turned into a 9,000-line single-page app built with vanilla HTML, CSS, and JavaScript. I used Matter.js for the 2D physics minigames.

A few technical takeaways from building this as a non-dev: * Managing the LLM workflow: Once the script.js file got large, letting the models output full file rewrites was a disaster (truncations, hallucinations, invisible curly-quote replacements that broke the JS). I started forcing them to act like patch files, strictly outputting "Find this exact block" and "Replace with this exact block." This was the only way to maintain improvements without breaking existing logic.

* Mapping physics to CSS: I wanted the minigames to visually sit inside circular CSS containers (border-radius: 50%). Matter.js doesn't natively care about your CSS. Getting the rigid body physics to respect a dynamic, responsive DOM boundary across different screen sizes required running an elliptical boundary equation (dx * dx) / (rx * rx) + (dy * dy) / (ry * ry) > 1 on every single frame. Maybe this was overkill to try to handle the resizing between phones and PCs.

* Mobile browser events: Forcing iOS Safari to ignore its default behaviors (double-tap zoom, swipe-to-scroll) while still allowing the user to tap and drag Matter.js objects required a ridiculous amount of custom event listener management and CSS (touch-action: manipulation; user-select: none;). I also learned that these actions very easily kill the mouse scroll making it very frustrating for PC users. I am hoping I hit a good middle ground.

* State management: Since I didn't use React or any frameworks, I had to rely on a global state object. Because the game jumps between different phases/minigames, I ran into massive memory leaks from old setInterval loops and Matter.js bodies stacking up. I had to build strict teardown functions to wipe the slate clean on every map transition.

The game walks through electrostatic desalting, fractional distillation, hydrotreating, catalytic cracking, and gasoline blending (hitting specific Octane and RVP specs).

It’s completely free, runs client-side, and has zero ads or sign-ups. I'd appreciate any feedback on the mechanics, or let me know if you manage to break the physics engine. Happy to answer any questions about the chemical engineering side of things as well.

For some reason the URL box is not getting recognized, maybe someone can help me feel less dumb there too. https://fuelingcuriosity.com/game

I built Site Spy after missing a visa appointment slot because a government page changed and I didn’t notice for two weeks.

It watches webpages for changes and shows the result like a diff. The part I think HN might find interesting is that it can monitor a specific element on a page, not just the whole page, and it can expose changes as RSS feeds.

So instead of tracking an entire noisy page, you can watch just a price, a stock status, a headline, or a specific content block. When it changes, you can inspect the diff, browse the snapshot history, or follow the updates in an RSS reader.

It’s a Chrome/Firefox extension plus a web dashboard.

Main features:

- Element picker for tracking a specific part of a page

- Diff view plus full snapshot timeline

- RSS feeds per watch, per tag, or across all watches

- MCP server for Claude, Cursor, and other AI agents

- Browser push, Email, and Telegram notifications

Chrome: https://chromewebstore.google.com/detail/site-spy/jeapcpanag...

Firefox: https://addons.mozilla.org/en-GB/firefox/addon/site-spy/

Docs: https://docs.sitespy.app

I’d especially love feedback on two things:

- Is RSS actually a useful interface for this, or do most people just want direct alerts?

- Does element-level tracking feel meaningfully better than full-page monitoring?

Harbor crossed its 127th (next one is special) release.

One notable added feature is ability to manage all my LLMs with a single CLI.

# list all models harbor ls # pairs well with jq harbor ls --json # Ollama harbor pull qwen3.5:35b # llama.cpp harbor pull unsloth/Qwen3.5-35B-A3B-GGUF:Q8_0 # vllm (HuggingFace Hub cache) harbor pull Qwen/Qwen3.5-35B-A3B

# Remove any of the models by the same id # used to pull it harbor rm <id>

Hopefully it'll be useful for someone too.