Show

Hey HN, I’m Eric and I want to share an OSS project that I’ve been building in my free time. Yogurt is a free, MIT licensed desktop app that uses on-device AI models to transcribe, summarize, and chat with your meetings.

Here's a quick demo video: https://www.youtube.com/watch?v=BFfbXAwRq98

Similar to Granola, Yogurt runs in the background and does not join your calls. But unlike Granola, Yogurt is open-source, free to use, and private. Your meeting transcripts, call recordings, and summaries never leave your computer.

As small OSS models have gotten faster and more powerful, Yogurt seemed like a pretty obvious win for privacy and cost conscious folks. You do not need a frontier model to summarize meeting notes or answer questions about them. And if you want to make your notes available to a frontier model, you can just share it with Anthropic, OpenAI, etc. directly via Yogurt’s local MCP server. There’s no need to use a paid cloud service as a middleman.

I tried some of the most popular OSS note taking tools, and most were missing features like calendar integration, MCP server, etc. or required you to connect or create an account. And more than that, they didn’t feel polished enough for it to be something I actually wanted to use daily, and so I built Yogurt to scratch that itch. I spent a lot of time fine-tuning every UI interaction/animation and optimizing the model calls to get the most out of your hardware + make it snappy.

To support Windows/Mac/Linux, I decided to go with Electron. I use whisper.cpp for transcription and Apple’s on-device SpeechAnalyzer if your system supports it. For call summaries and questions, I use a local open weight LLM that automatically gets downloaded and set up based on what your hardware can handle without your cooling fans firing off like crazy (this part uses llama.cpp).

I’ve spent a lot of time working on details like echo detection/reduction, global/folder/local level search respectively, and auto-end recordings. Hope this is useful for any of you who have held out on using AI note tools for privacy or cost reasons, or for folks using cloud tools who want to switch to something free and open source that still feels great to use.

Would love to hear what you think about the onboarding and note taking experience :)

No internet connection needed. Uses a locally-installed compiler for assembly generation.

I have been developing Micron (for "MicroOberon"), a lean, statically typed, modular systems programming language that combines Oberon’s simplicity and explicit module structure with C’s low-level capabilities and interoperability.

Micron is not my first langage design. I first built Oberon+, a modernized and unified Oberon, in order to under­ stand, by implementing it and by porting real systems to it, what Wirth’s design actually gives and where it fails. The systems ported to Oberon+ included the 2013 Project Oberon System and different versions of Oberon System 3. I then explored the opposite direction with Luon, a higher-level language for managed application progamming. Micron is the synthesis of this and my 30 years experience with C/C++ in systems programming.

The goal of Micron is to use the same language for boot code, device drivers, an operating system kernel, and ordinary applications, without requiring a garbage collector or routing machine access through a separate, unchecked system dialect (such as Oberon's SYSTEM.ADR/GET/PUT which operates on LONGINT). The language supports explicit memory layouts, signed and unsigned integer types, pointer operations, and direct calls to C without wrappers. One of its central design choices is language levels. Each module declars the level and thus the feature it needs, ranging from code that requires neither stack nor heap to garbage-collected objects. A module can import only modules at the same or a lower level. For example, a kernel module declared at level 1 cannot accidentally acquire a dependency on heap allocation through an import. Other features include generic modules, structural interfaces, and compile-time procedures. Much of what would require a preprocessor in C is expressed through typed language features.

There is a working compiler, interpreter, and IDE, along with a free textbook (http://software.rochus-keller.ch/micron-textbook.pdf). The book explains both how the language works and the reasons behind its design. Its systems-programming section walks through a port of Wirth and Gutknecht’s Project Oberon operating system to Micron, cross-compiled and linked into a single executabl that runs on an emulated RISC-V machine.

The examples also include ports of a Smalltalk-80 VM, Scheme 9, and the original P4 Pascal compiler. The compiler and interpreter implement the language specification; native backends and tooling are still work in progress, and the current native code generation prioritises simplicity over optimisation.

For more information see https://github.com/rochus-keller/Micron/blob/master/Readme.m....

I've been developing applications for a long time and have turned to game development as well lately. One of the things that frustrated me the most was that using AI agents for game development is very annoying in the art department. Your only options right now are to either use an image genAI model and roll the dice every time you want to make an edit, or have your agent draw with something like vectors.

I was looking for an application that would allow me to ask an agent to make a first draft of whatever art I needed with actual brushes, and then be able to go in myself and edit every last stroke or layer that it created.

Klad is that application. Written in Rust, it can be fully controlled by an agent through the CLI, and every function is available in a nice UI as well: a brush engine, frame-by-frame animation (and bones/IK), vectors, text layers, colours, layer effects, infinite undo (even after re-opening the file!),…

Why I think it's useful for a wider audience: Adobe showed agents editing Photoshop files at MAX this week, with a private beta planned for early 2027.

Klad is built on the same core idea, with editable paint strokes as core architecture, and it works today.

Clone the repo to try it out: https://github.com/klad-app/klad

You can basically point Claude to the repo, ask it to build it, and pick up the drawing skills. Then ask it to make any drawing you want! (After that, you or the agent can change absolutely every brush stroke in the app again, which makes edits a breeze.)

The quality of the drawings really depends on the agent you use. I have tried it with Claude Fable 5.2 since it came out on Monday, and the drawings are already quite impressive. I'm confident that this will only improve.

I use it every day on Mac, so that definitely works well. It builds on Linux too (tablet pen pressure still needs some work there). Windows builds in CI, I haven't used it there myself yet but I have some reports that it works perfectly fine.

Coming up next is support for pixel art. I'm in the testing phase with this right now, and I expect it to go live in the repo sometime this weekend.

Klad is source-available rather than open source: free to build and use for individuals and small companies, and I plan to sell pre-built binaries later, the way Aseprite does. The file format, CLI reference and agent skill are MIT.

What I want to hear from people who try it: Can your agent work out the CLI without help, and where does it get confused? Can you go in and change one of its strokes easily?

The command reference and guides are available at https://klad.studio

I'll be here answering any questions about the technical side as well, as it's a pretty interesting challenge to build a performant engine with editable brush strokes that render as paint.

I haven't been able to find any good iOS apps for exploring grandmaster chess games. I used to use Lichess but their feature for browsing master games on iOS is broken for me.

I made ChessKeep so I could filter by master and opening, and it's a PWA so it can be installed to your home screen. Please share any feedback!

I grew up with Black Ops 2 and wanted to see if I could make it work on my 2020 MacBook Pro. So I used Claude Opus 5.5 to create a tool that converts your copy of the game (from Steam) to a native ARM64 Mac app, with almost 60fps in all areas. The whole game is statically recompilated ahead-of-time (AOT) and does not use any emulator whatsoever, be it Wine, Crossover or Rosetta. The best thing is the performance, although some heat issues are still to fix. You get to play the whole Campaign, local Multiplayer (with bots) and local Zombies (all DLCs maps; you need to have them in your Steam library obviously) at about 60fps. Split-screen was not in the PC version, but I've been working on it lately; it's coming soon! LAN mode is on the roadmap for later too :)

Using SQLite in Go is deceptively easy. If you just import the popular github.com/mattn/go-sqlite3 as the database/sql driver implementation and start making queries, things will work great until you start hitting SQLITE_BUSY errors as traffic increases.

Then you go down the same path of many gophers before you, finding GitHub and forum posts providing conflicting information on best practices for pragma values and connection handling.

So I created https://github.com/cattlecloud/litesql

Which provides a nice abstraction, making it easy to accidentally do the right things when using SQLite in your Go program. In particular it pools connections for read transactions and isolates a dedicated write connection for writes. It also sets pragma values to much more reasonable defaults, like isolation levels, foreign keys, cache sizes, etc. On top it provides a nice abstraction for creating periodic snapshots with retention policies. There is also litesqltest for one-line test database creation in unit tests.

Hopefully you or your agents might find it useful.

Hi HN,

I wanted something like workerd + celld for untrusted Rust apps and couldn’t find anything that quite fit. That said, I got a lot of inspiration from workerd, celld, spin, and wasmcloud.

spared (spare-dee) runs Rust apps + SQLite in isolated WASM sandboxes. It lets you run many apps per server, and by packaging SQLite inside the sandbox, you get better isolation than running it on the host. This opens the door to running untrusted code on a single machine.

It's open source and runs on any VPS.

It's still early, and there's still a lot to build, but it feels like it's at a good place to share. Let me know what you think.

Repo: https://github.com/michaelmagan/spared

I'm Kam, co-founder and CTO of Nitrosend.

Email is our lifeblood, so we've been gradually moving our email sending onto bare-metal servers and IPs we control.

We wanted to make that move without rewriting the application code already calling Amazon SES. So we built NitroMTA, an open-source SES replacement in Rust. We kept our existing SES v2 sending calls and changed the endpoint and credentials to send through our own engine.

We've been running it in production for a few weeks, moving more mail over as we warm our IPs and build reputation with each mailbox provider.

Keep the SES integration

For an application using boto3, this is the client configuration:

  import boto3
  
  ses = boto3.client(
      "sesv2",
      region_name="us-east-1",
      endpoint_url="https://mail.example.com",
  )

For the SES v2 sending operations we support, the existing calls keep working. We test the official JavaScript, Python and Ruby SDKs against the engine, along with Nodemailer and django-ses. The compatibility page lists the operations and differences from SES: https://nitromta.com/docs/compatibility/

Measuring against KumoMTA and Postfix

In our published 2 November comparison, NitroMTA sustained 3.16 times KumoMTA's throughput and 4.11 times Postfix's. These numbers measure SMTP submission and delivery.

  Engine                Messages per second
  NitroMTA              3,313
  KumoMTA               1,048
  Postfix with OpenDKIM  806

Each engine had four CPU cores and 2 GiB of memory on the same AWS c7gd.metal bare-metal server, with its queue on local NVMe. The workload used 16 KiB messages, authenticated SMTP submission, TLS on submission and delivery, and RSA-2048 DKIM signing. Every engine committed a message to disk before acknowledging it.

The figures are medians of three interleaved runs per engine. The quick profile searches for the highest rate meeting its latency budgets using ten-second load steps, delivering to one receiver site with no added network delay. Across the nine runs, the harness sent 1.35 million messages and checked that each arrived once, with its body intact and its DKIM signature valid.

KumoMTA used its RocksDB spool with set_force_sync(true) to meet the same acceptance contract. KumoMTA documents that this forces database-wide flushes and can substantially reduce performance. The comparison is for that synchronous-acceptance contract; the harness also supports measuring its default asynchronous mode separately.

The method, configurations, exact versions and raw results are published, and you can run the comparison with cargo harness quick: https://nitromta.com/docs/benchmarks/

Give each IP a budget for each provider

An IP needs a sending history with the receivers it sends to. We need to decide how much volume it gets today, what earns it more tomorrow, and what makes us back off.

We track the budget by sending IP and receiver group. That lets us hold an IP's Gmail cap while increasing its cap elsewhere, or lower its Outlook.com cap when Microsoft's responses call for it.

With warmup enabled, the shipped ladder starts at 50 messages a day. A day needs enough SMTP outcomes to test its cap before it earns an increase. Complaints, failures, deferrals and throttling can hold the cap or move it down a rung.

The Outlook.com defaults take fourteen clean daily increases to reach 10,000 messages a day. The default ladder takes seven. Both are configurable.

Before any of this, the host needs outbound port 25 and reverse DNS control for its sending addresses. The domains need SPF, DKIM and DMARC, and bounce and complaint reports need somewhere to arrive. We put the setup checks in nitromta doctor, which prints the missing records.

Provider feedback and durability details continue in a reply.

I tend to make a lot of scratch notes as a way to help me think. These usually don't last very long and what does survive usually ends up in a git repo, a wiki or (most often) just gets thrown away.

I was using Obsidian for this, but gosh, 4 or 5 Electron processes just for throwaway notes seemed like overkill. Neovim is a better fit but I like it just the way it is for coding and didn't want to install any image plug-ins for that.

mib is a bit like a basic Vim editor, with a few Obsidian features cherry-picked and a workflow optimized around scratch notes (with just 9 glorious pages - no files or folders to organize).

It's called "mib" because it is, and always will be under 1MiB (currently < 300KiB). Its a fully local, native app that is smaller than some JavaScript frameworks.

Disclosure: I still write a lot of code by hand but this project is 100% AI generated (Claude and Codex). I was a tough taskmaster though - we worked through a lot of approaches to arrive at something this small.

Hi, I'm Mike, I've made ThingStudio, a flow programing environment for microcontrollers. It allows drag and drop programming Node-RED style, but emits MicroPython which it uploads to the micro. The board does not need the editor to run after that. Runs fully local, Apache 2 licensed. There's a functional version of the editor/IDE at linked to the home page, you'll need to install to be able to upload, because WebSerial is not universal. Please give it a whirl. I'm happy to answer any questions.

Browsers natively handle a lot of what used to take 50 lines of JS (or a dependency): `CSS.highlights` for text range highlighting without <span>s everywhere, `<dialog>` and showModal() give you backdrops and ideal focus management, `field-sizing` to auto-grow textareas as the user types.. (Something yesterday's ftrain post touched on [0])

Models know about some of these by name, but consistently won't default to using the platform-native solution and instead prefer the incumbent <div>+JS based pattern. We started an effort in Chrome to supplement coding agents with this key domain knowledge and we're shipping our 1.0 today, in collaboration with Firefox, MDN, and Edge.

200+ guides (~1.7MB) of curated, hand-crafted implementation best-practices from web experts, updated as the web evolves. (Open source, obv, so.. we'll welcome your bikeshedding ;) Readable versions here: [1]

I've spent the last 9 months obsessing over how to ship this as an agent skill + (Agentic RAG) CLI without blowing up your context window. (Or cedeing activation mechanics to MCP dynamic tool search). The skill description is minmaxed for activating on relevant frontend tasks. The RAG work I'm pretty proud of… originally a 500mb native stack down to a ~7MB pure-JS package, ~10ms search on your CPU.

We just introduced a deterministic 'legacy-scan' (trained on 30k github repos) to identify old 'n dusted patterns that your agent can modernize. (92% avg precision on held-out repos.)

People make a lot of claims about what coding agents are good/bad at. We wanted receipts, so we invested heavily in eval infra [2] to help us hill-climb, but also to identify when knowledge is common enough we can prune our guides. (Ofc, some of the things we thought AI didn't know turned out to be wrong :) We run codex/claude/agy against 200 tasks without the skill and then with.. In total ~1,700 playwright/AST-based assertions. Agents go from 55% pass unguided to 92% guided.

Try it out:

    DISABLE_TELEMETRY=1 npx modern-web-guidance@latest install
    DISABLE_TELEMETRY=1 npx modern-web-guidance@latest search "animate dialog modal"
    DISABLE_TELEMETRY=1 npx modern-web-guidance@latest legacy-scan ./src

If you spot something wrong or weird, give us a holler!

Longer write-up on the 1.0: https://developer.chrome.com/blog/modern-web-guidance-v1

---

0: https://news.ycombinator.com/item?id=50416456

1: https://developer.chrome.com/docs/modern-web-guidance/guides

2: https://googlechrome.github.io/modern-web-guidance-src/

hey HN, i built this because I'm a satellite nerd who was bored this past weekend.

type in any place and it finds every satellite that passed over it in the last 7 days (SGP4 on the CelesTrak catalog, tracking 17k+ objects and runs in your browser in about half a second), then pulls the real Sentinel-2 / Landsat / NASA images from those passes.

fun fact: all ~17k objects in orbit are drawn on the GPU, solving Kepler's equation every frame. also cool is that Sentinel-2 timestamps are often 5-10 min off from when the sat actually crosses your spot, so some cool math was involved in making it accurate on the site.

it only shows real images taken from those exact satellites, and it never store your location.

code: https://github.com/dev-Armaan/satellites

would love feedback, contributions, or whatever else you guys can offer!

NoDOM replaces Chrome's DOM, CSS & HTML rendering with a custom WASM engine designed for high performance and minimal latency in Modern Data Oriented C++ for a zero alloc zero copy render hotpath. The aim being to minimise tick-to-render latency. GUI layout and data declarative JSON are served via websocket after initial page load, or can be packaged in an HTML shell like the UK property demo. The layout JSON supports embedded Forth fragments for "glue" computation. NoDOM can also call out to JS both synch and async. NoDOM builds on top of Dear ImGui and ImPlot, and builds to wasm with emscripten, and win32 with MSVC 2022. NoDOM is closely integrated with DuckDB-WASM; any table can be rendered as a grid or chart. I designed NoDOM with financial market trading apps in mind, having seen quants and traders frustrated by slow Plotly charts. Ultimately NoDOM should make it possible to show users dynamically generated high performance dashboards.

https://github.com/osullivj/nodom https://github.com/osullivj/nodom/wiki

Hi, here's a TUI we originally created for internal use. The goal is to be able to control multiple Claude Code sessions running in parallel while being able to review the changes and to understand the design choices the agents make.

The key design principles are:

- the programmer's attention is the bottleneck, so instead of cycling between sessions to find what's waiting for user input we use hooks to push work to the attention queue, i.e. let work come to you, not viceversa

- easy change, review and comment loop: [tuicr](https://tuicr.dev/}-inspired code reviews. Easy to add comments and send them to agents

- unobtrusive tooling: run on tmux sessions, connect to claude code via hooks, no complex dependencies

- quiz mode: answer design questions about the code to verify and reinforce your understanding of the changes

- keyboard-first navigation with vim keybindings

Comments, ideas and PRs all welcome!

Hi HN, I'm Crokily. Pots is an AI coworker that lives in the chat your team already uses: Slack, Discord, Telegram, or any channel with a Chat SDK adapter. It is MIT-licensed and runs on a machine you give it, with the model you choose.

To be honest, the first time I used Grok Bot, its design really impressed me. Unlike OpenClaw before it, it was not just Claude Code connected to a chat app. It truly cared about how it works with people. It felt like a living AI assistant, and working with it was painless. That is the idea I kept learning from the whole time I built Pots: it is not an agent hooked up to a chat channel. It should be a coworker that feels alive and is comfortable to work with.

But Grok Bot is only Grok's bot. Which model you get depends on your X subscription, your data and your machine are all in the cloud, and most of all, it is a standalone app, and most of its features serve that app.

Pots is a bit different. In Sydney I have talked with quite a few founders. Grok Bot is good, and it helps them a lot with their personal tasks. But when I asked who had actually put Grok Bot into their company's work to make their startup team faster, nobody had. So I think Pots is in a different place from Grok Bot, and from most open-source Grok Bot alternatives: it grew out of what real startup teams need. Before I open-sourced it, 6 small startups I met at startup events had been using it with me for over a month.

Pots is built first for the channels startup teams already work in, not for an app of its own, so most of what it does serves the places where you actually work. The teams use Pots as a middle layer: a CEO talks ideas through with the team in chat, Pots listens, and then it builds a prototype that both sides can check. They use Pots for competitor research: because Pots runs inside their channels, it knows their product well. Not only the GitHub repo, but the team's daily discussions and what the team cares about. Pots has been listening quietly the whole time, so it knows the product with no setup at all. It also works well with each channel: it talks to people with the channel's own controls, like Slack and Discord buttons and cards, and when it hands over something complex, it deploys a page with its built-in server so everyone sees it in a better form.

So Pots is different from Grok Bot and from most open-source alternatives. It came out of what real startup teams need. Its channel features start from what each company's work needs, and it can join your real work setup with no setup and still do well, instead of being one more app that nobody uses and that is hard to start with. And it ran in real business for a while before I cleaned it up and open-sourced it.

The difference from Grok Bot is also exactly why I made Pots an open-source Grok Bot alternative. I have OpenAI and Claude subscriptions with plenty of quota, and my own servers, so I don't want an X subscription to limit me. I want to use whatever model I want and do whatever I want. I can even switch to an open model, and none of my data goes into anyone's pocket.

Try it (Node 24+, macOS, Linux or Windows): the easiest way is to ask your coding agent (Claude Code, Codex, Cursor) to read docs/for-agents.md in the repo and set up Pots for you. Or by hand: npm install -g pi-durable-bot, then pots init.

I'd love feedback, especially on how it decides when to act.