2026年6月9日 的 Show HN

Just for fun and self education, I've built this over a weekend to teach myself why orbits exist, not just show planets going around. Something that was never clearly explain to me in school. It opens with a guided tour that builds the idea up step by step: two bodies and the equal/opposite force, inertia (the Sun is removed and Earth just drifts straight), then "an orbit is falling and continuously missing," cosmic velocities with a little rocket, Voyager 1 & 2's real gravity assists (the clock runs the actual 1977–1989 dates so the planets orbit into their grand-tour alignment and the slingshots line up), and it ends on Einstein — gravity as curved spacetime, the classic rubber-sheet well. What's real: every body uses its real radius/mass and J2000 orbital elements; positions come from solving Kepler's equation each frame. You can toggle to an N-body mode (symplectic leapfrog) that shows live energy drift (~1e-6%) so you can see the integrator is honest. The only thing faked is scale — at true scale you can't see anything — so there's a toggle between true scale and a log-remapped "visual" scale, with physics always running in real AU. Tech: TypeScript + Three.js + Vite, fully client-side, no backend, works offline (surface textures are generated procedurally from value-noise; only Earth uses a real image). Source: https://github.com/qunabu/Gravity

Happy to answer questions — and feedback on the physics or the explanations is very welcome. This project might be totally inaccurate in terms of real physics, this is how i do understand this on my own - i'm happy to confront this with reality

At Deno we've been using OpenClaw and other agents increasingly for addressing production problems in Deno Deploy - when a PagerDuty alert fires, the agent starts researching the cause and making fixes.

In order to do this, the agent needs access to real production systems - postgres, kubernetes, gcp, clickhouse, github, etc. But this is dangerous to say the least - we want destructive actions to be reviewed by other LLMs, approved by humans, and logged appropriately.

Claw Patrol terminates TCP connections over WireGuard or Tailscale, then parses application protocols (eg http, postgres, ssh) to apply rules that allow you to deny/allow requests.

There are a few projects that sit as a proxy in front of agents to do secret injection or apply various guardrails, but none met our needs (LLM gateways, MCP proxies, sandboxes), particularly the need to handle low-level protocols, or handle complex real world situations like tunneling postgres through k8s.

Written in Go, configured in HCL, MIT licensed. Happy to answer any questions.

Commodity FDM print strength is limited by poor Z-axis layer bonding. Parts crack along Z under stress. MAGMA tries to fix this in software that works on any FDM 3D printer.

It's a fork of OrcaSlicer with a new infill type that creates paired U-shaped vertical channels inside the print, plus G-code that injects molten plastic into those channels to bridge Z layer interfaces with continuous plastic.

Big caveat: I have a junky Ender 3 and haven't gotten a clean physical print yet. Don't expect this to work out of the box! After months of tinkering, I'm releasing the software so the 3DP community can experiment with nozzles, multi-material, weird hardware, and other print parameters I can't. There's around 40 MAGMA-specific settings to fiddle with, plus some general quality-of-life features (e.g. printing thin infill sections as solid, and a "dual infill shell" feature that applies MAGMA only to the outer shell to save print time).

THIS CODE IS ALPHA. Around 50 prints old. The injection G-code is novel. Some printer firmware won't like extruding without movement. In extreme cases it could damage your printer or start a fire. DON'T WALK AWAY WHILE PRINTING.

Why MAGMA? "Lava tubes" is a misnomer. Molten rock is magma underground, lava only after it surfaces. The injected tubes are buried inside the print, so "magma tubes" is the correct term.

Hi HN. My name is Andrey. On a regular business day, I'm a software engineer working at AWS. Outside of work hours, I spend time on my hobby - writing code.

I was once building a pet project that allowed customers to spin up fully synchronized blockchain nodes within just a few minutes. The backend was split into a control plane and a data plane, each with its own AWS account. Later I added two more AWS accounts. One for shared RPC nodes. One for the Analytics Service.

Since I love to visualize things, I used drawio to visualize the architecture.

With time, I noticed a pattern. I'd write some code, add a few lambda functions, update my drawio diagram, write more code, introduce a few more resources, test things, see that everything works fine and go to sleep with a smile on my face. Next week I'd check my diagram, and shockingly, it's missing some of the resources! This kept happening for a few more weeks until I decided to fully abandon the project until my infrastructure diagrams could stay in sync with my cloud account.

That's how Atlasphere.io was born. I've been working on it for the past 6 months and I think the product is ready for some feedback :)

A few notes:

- Atlasphere uses a ReadOnly IAM role to scan your AWS account (my account reaches your account through a trust relationship).

- The number of services is currently limited (WIP)

- It's a macOS app

- It's NOT an Electron app, i use Rust + Webview

What am I looking for? All I really need is for someone to try the app and tell me what they like about it and what they absolutely hate about it, haha!

The website is https://atlasphere.io/

Hey HN, here's the repo if you'd like to try it out: https://github.com/Kaelio/ktx

Would love your feedback.

For context, we started working on our general AI agent CraftBot before OpenClaw came out. It works similar to OpenClaw and Hermes agent: control your PC do task + memory + proactivity. However, here is the catch, it can create and operate its own SaaS tools with the concept of Living UI

Living UI is a system where an AI agent can scaffold and launch real, working web apps on demand. Each living UI can be a dashboard/software/internal tool. They are essetially just frontend with X techstack talking to a backend + database with the techstack of your choice , spun up in its own pair of ports as supervised subprocesses managed by a host process. The backend owns all the state (so the app survives page reloads, tab switches, even host restarts), while the frontend is just a dumb view that fetches data and posts user actions. CraftBot can create a project from a template, install dependencies and launch it. It can also read and write its data through a scoped HTTP client, plus built-in endpoints that return a DOM snapshot and a screenshot so the agent can see what's on screen.

Currently, there are 3 ways to create a living UI (1) Build from scratch. Just describe what you want, and CraftBot generates the backend, API, and UI, then iterates with you. (2) Install from the marketplace. Use ready-to-use apps built by the community (we are looking for contributors!). (3) Import your existing project or GitHub repo. CraftBot converts it into a Living UI and integrates itself into it (similar to CLI-anything, except the app runs directly in the agent UI).

The net effect: you ask for an app, the agent builds it, you use it like any normal website, and the agent can keep poking at it later.

I'm Dimitrios at Cosine. Quick orientation first: the read-only scan is free and you can run it right now: that's the part to try. The pen-test mode is gated behind written authorisation, because it's live offensive testing against real systems; I'll explain that below, it's not a paywall thing.

The reason `cos` exists: most "AI security" tools wrap a general model, so they inherit its refusals — point one at a real offensive task and it hedges or declines, because the base model was trained to. We went the other way and post-trained our own model for offensive security, so it does the work instead of apologising for it. It's our model, not a wrapper.

Under the hood it's a multi-agent swarm: an orchestrator splits the job across subagents running in parallel, each owning a slice, then synthesises one report. That's what gets a polyglot microservice repo done in one pass.

The fair objection to a model that doesn't refuse, pointed at your code: how is that not reckless? I think refusals are the wrong layer to put safety in. A model that refuses is both useless (won't do the job) and unsafe (you're trusting a probability distribution to hold a hard line). So we don't ask the model to behave — we enforce it in the harness. A runtime guard written in Go intercepts every tool call before it runs. In scan mode it hard-blocks every mutating tool and any non-read-only shell command — the model can decide whatever it wants, the guard won't let it write. In pen-test mode the same guard pins the agent's network scope to the targets you authorised; it can't reach anything else. Safety is deterministic and sits below the model, not inside it.

Two modes, one CLI:

- Security Scan — read-only audit of a local codebase, every finding tied to a file and line. Free, runnable today.

- Pen Test — the swarm attacks systems you authorise and hands back the request it sent and the response your code gave. Gated behind written authorisation.

Demo target, and I'll be straight about it: Bank of Anthos, Google's open-source reference bank. Known app, some intentionally-soft bits — which is why I picked it, so you can reproduce the run instead of trusting a screenshot. The scan found an integer overflow in the transfer path that would let you forge an account balance, plus the usual injection/auth/secrets classes.

It's a closed binary (brew/curl/winget), runs locally, by Cosine. Run it behind a firewall and `tcpdump` exactly what it does before you trust it on anything real. Install is free; the scan runs on a $20 Cosine subscription; pen test is scoped per engagement.

I'll be in the thread all day. The harness-vs-refusals design is the part I most want torn apart — tell me where it breaks.

Alot of companies (Including the one i work at fulltime) use third party email builders to provide custom email functionality to users. However this is a niche sector and the prices are... insane?

So to try and fix this i built Maillune, a embeddable emailbuilder sdk that is alot cheaper with a usable free tier for hobby projects. The entire goal was to make the features transparent and logical. With lower focus on feature paywalls and aiming on a more "Out of the box" approach.

This is one of my recent projects ive built in parallel with my fulltime job. All feedback is welcome, good or bad!

Hi HN,

This is a project I've been working on since the beginning of 2025 full time, without funding.

Coding agents have fundamentally changed the way we write software. When you let an agent write code, pull dependencies, and run scripts, you are delegating trust while still keeping the responsibility. You shouldn't have to choose between moving fast with agents and maintaining basic control over your host machine.

Normally, we just inspect the final result, treating the app like a black box. Most security tools only sandbox the app runtime and ignore the build phase.

CapaKit is my attempt to make agent-driven development safe and productive.

Secrets baked into config, dependencies installed with full host access, and arbitrary scripts running during `npm install` are all things you need to take into account.

I started working on CapaKit in early 2025 (originally as mcpgate.com) after Anthropic announced MCP. As the agent ecosystem started to standardize, I wanted to apply what I've learned building with LLMs since GPT-3. Building real AI apps turns out to be really hard: lots of moving parts, from security to devops, on top of a fast-moving ecosystem.

What is special about CapaKit?

CapaKit sandboxes the entire app lifecycle, not just the running code- building, testing, and running, all first class citizens of usability and security.

What that means concretely: - Per-app policies with workload-level isolation. - No inherited host environment, no broad filesystem access. - No network by default — outbound traffic has to be explicitly allowed. - Ephemeral, single-use sandboxes for every build and run. - Secrets resolved on demand instead of hardcoded.

Security with awesome usability: you can upload your AI app Kits to Github and anyone can run them with a single command:

capakit run https://github.com/capakit/hello-world-demo-kit

CapaKit is currently macOS only and is free to use.

I’ve been working on the next version of Serverpod, an open-source backend written in Dart for the Flutter community. We are getting close to a final release. This version brings stateful hot reload to the full stack (server, database, web, and app).

Under US law, typefaces are uncopyrightable, but the font software is. This is a tool to reproduce typefaces via fully automatic clean-room reimplementation of the font software.

I am a 40 years old jobless sys-admin with no cs degree and no development experience and 25 yeras of system knowledge. I built a fully encrypted writing environment where I can write with focus forgetting about the application. Here ai was my code translator while I strictly was the architect and instructor. It all started when i asked myself that "why and how i remember any past memory instantly without searching inside my head". This became the design principle of my app. Thus I solved a fundamental git problem of tracking a single note throughout the history by embedding uuid in every commit.

Its responsive data-as-UI based interface keeps the app (nearly) learning curve free. Navigating deep hierarchies is easy using numbered fisheye jump system without forward button. Every operation is in one or two keystroke like v(view), c(create), d(delete), r(rename), (j)ump s(sync), (s)earch, b(back) or v1, d1, j1, jb etc. It is built using python standard library (no other dependency), Git, cryptography standard primitive (embedded). I used git-filter-repo programaically for permanent item erasure using uuid from inside the application. It has full timeline for each item (note, file, subnotebook) to see the entire life cycle from create to erase with tombstone. Its subnotebook hierarchy can be upto any depth. It supports 80 file types with syntax highlighted editing with export feature for files. It has activity viewer inside every notebook or subnotebook. It shows your last 50 activities in the notebook. Searching is easy like "s files* file.md date* 02-04-2026 in* notebook/subnotebook_name", "s note_name date* 01-04-2026 05-04-2026", "s edited* any_text thisweek" "s in notebook/subnotebook_name" or just "s anytext".

Notebook can be encrypted using 8-24 words BIP-39 phrases and use password for regular lock/unlock. It is encrypted using standard AES-GCM and also portable. It can show password change log in each notebook management screen. Key vaults are hardware bound yet portable and a usb drive can act as TPM like security. It means when the keys are not reachable, notebooks can't be accessed. The application architecture and data structure is decoupled. Where app architecture allows the app, notebook and key vault can be in three different locations or even in different systems and data architecture allows metadata and content remain separated in different files inside each notebook folder linked via UUID. Git is implemented for doing item level (not file level) versioning and temporal search with uuid based commit metadata. Here commit metadata is not encrypted, though doable modifying the existing code if required. Every notebook is self contained in just a movable single folder. The architectur also enables optional e2ee conflict free sync using github and other platforms. It does not need someone to be a git expert to use the application and cloud vendor cannot see the data even with public visibility.

I will request respected HN people to go through the documents and the story_n_constraint.md file, that will explain the what, how, why in details. I also put a couple of abstract ideas inside the repo (what_can_be_done files). I want to thank the creators of Python, Git, cryptography, nvim, micro and git-filter-repo. Their tools came together and turned a concept into a working application.

The post, the GitHub repository, and all source code and documentation are part of the prior art with appropriete license (Public + timestamped + enabling)

repo: * https://github.com/sys-ronin/terminal-notes *

requirement: linux/mac/win/docker, python 3.13, git, nvim/micro or any terminal based editor (can be configured from config.json inside root folder),internet for using github sync example - python3 terminal_notes_ui.py (from linux) * tested on debian 13 only

git clone https://github.com/sys-ronin/terminal-notes.git && cd terminal-notes && python3 terminal_notes_ui.py

sys-ronin

Hi HN! Here's a little game I (and my buddy Claude, cf. the obvious CSS gradient tell) set up to explain to my kids some of things we were working on at work.

So in the game you're taking turns moving coins down a line until no moves are possible. If you've taken a course on combinatorial game theory, you'll have come across the game of nim and you can think of this one as a variant of nim where there can only be a single coin in every square. The theory of how to play it isn't quite as well-established as for nim though; play with enough coins and I certainly find it quite tricky to mentally reason about whether a position is good or not.

One fun fact about Welter's game is that its winning positions form the codewords of a particular error-correcting code called the constant weight binary lexicode (Conway and Sloane, 1986). What that means is that being good at the game is the same as being good at decoding messages in that code. Probably more fun to just play the game though.

I mostly wanted to prototype hardware ideas quickly, with as little as possible between writing a circuit and watching it run. There are already solid embedded HDLs in general-purpose languages i.e. Chisel (Scala), Amaranth (Python), SpinalHDL. They all also have their own simulators, but they live inside the JVM or Python toolchains. I wanted something I could open in a browser and just start building, with nothing to install. If anyone is familiar with the game Turing Complete on Steam it was a big inspiration behind this. I just hated having to wire the gates manually.

Simten is a hardware description language that's plain TypeScript. A circuit is a typed value you simulate cycle by cycle, in node or the browser, with an interactive view you can drill into and toggle back and forth across cycles. There's nothing to install to see it run, and a circuit drops into a web page as a live component. It still exports Verilog for the existing primitives (very early, flat module) when you want to take a design further. Also since it is TS, you can do cool things like use existing libs from npm and integrate them into the simulation at compile time i.e. load in data, bake it into the ROM and then run it. The figlet example on the landing page hero shows this in action.

There is also an MCP that allows you to build with Claude and push to the browser locally (I know most probably won't want to learn the syntax).

As for what I have done with it so far:

- snake/pong at the gate level (actually harder than it sounds!) - rv32i (risc-v) CPU that is able to run C/C++/Rust compiled with GCC/rustc - run the output verilog (alongside a few board-specific extras) through the OSS FPGA toolchain i.e. Verilog -> Yosys -> nextPNR -> flashed and running on my ULX3S

Interested to hear what you think and if people would actually use it. I was thinking the interactive aspect of it could be useful in CS courses. So letting students see pipeline hazards happening cycle by cycle instead of a static example in a textbook.

- simten.dev/circuit — the playground (write/simulate circuits) - simten.dev/cpu/rv32i — the RISC-V CPU you can step through - github.com/simtenHQ/simten — the repo

AI-native red-team workbench for authorized penetration testing and vulnerability research, with specialist agents, sandboxed tooling, evidence records, and replayable timelines.

I guided Claude to write an SPA to make the BATFE Annual Firearms Manufacturers And Export Report (AFMER) data easier to explore.

I have the raw data in https://github.com/ryjones/AFMER . I've been collecting the raw data since 2005 or 2006 as it became available.

I started grabbing the data years ago to interrogate claims firearms manufacturers were making in public about sales volumes against the data the BATFE publishes.

Hey HN, cofounder of Artie here. I’ve been working on real-time database replication using CDC (Postgres/MongoDB into Snowflake, BigQuery, Redshift) with my wife for the last three years. Last time I posted here, people had to book a call with us to get access, but that’s no longer the case. You can connect your source and destination and start streaming immediately.

I encountered this problem firsthand as a heavy data warehouse user at prior jobs. Our warehouse data was always lagged and analytics were always stale. The most visceral version of this today: imagine an AI agent making decisions – on pricing, support routing, risk scoring – off a data warehouse that's 3-12 hours behind.

When we started, I thought the hard part was reading the WAL. The real problems:

Schema drift: CDC events carry row data but not column metadata, so when an engineer adds a column in prod, events with that column start arriving at the destination before you've run ALTER TABLE. In this case, you wouldn’t get an error – you would just silently drop data.

Backfill race conditions: the typical approach (snapshot first, then start CDC) means by the time your snapshot finishes on a large table, the stream has moved on. If you stitch them together wrong, you overwrite newer data with older snapshots.

Kafka offset commits: this sounds obvious but they’re difficult to execute. You can only commit after a successful merge into the destination, or you double-write on replay. Partial failures across a distributed system compound this quickly.

TOAST columns: Postgres omits unchanged TOAST columns (large text/JSON/bytea – think JSONB config fields, long descriptions, binary blobs) from WAL events entirely for storage optimization. A naive pipeline reads ‘missing’ as ‘set to null’ and silently wipes valid data, which can mean a customer's entire config blob gets wiped out because an unrelated column on the same row got updated. The fix is merge logic that treats absent columns as ‘don't touch’ rather than ‘set to null,’ which breaks most off-the-shelf UPSERT patterns.

Curious whether others have hit these same walls building in-house, and would love feedback.