ericr.org

Godot Town: Claude built a medieval town from one prompt

2026-10-20T12:00:00Z

The usual way to find out whether a game engine can handle a big scene is to read forum threads where people argue about it. This time I asked Claude to build one and find out.

Godot Town (the name took less time than anything else in the project) is a medieval town you can run around in, made with Godot 4.7. Claude built all of it: Claude Opus 5.5, running in Claude Code, from a single prompt, in about an hour. I didn't write a line of code, pick an asset or place a house. It has terrain with real elevation, a humpback stone bridge, a castle on a hill, about 140 houses, 1,500 trees, a crowd of villagers, farm animals and a river you can swim in. Here's a minute of running around it, including a trip through the time-of-day cycle:

Godot Town, recorded at 1600×900 with the HUD on. No sound, because the town doesn't make any.

One prompt

Before this, Claude had built a couple of small test games so I could compare Godot with Stride, and Godot came out ahead. The next question was how far Claude could take it. This is the whole prompt, sent along with a sample image of the look I wanted:

Can you build another game in the folder ‘GodotTown’ where I can run around through a medieval town? Are there stock assets of any kind similar to the Unity Asset Store? If so, some nice buildings and animals would be great. How much can you do - can you create 3D assets on your own and create 3D models that can be rigged and animated? I want to see how the game performs with elevation changes (like running over a curved bridge that bends upward) and I would love to have the ability to jump when pressing the spacebar.

I would like to keep the graphics simple but pretty - similar to the image ‘sample.jpg’ in the folder. I want to see how much we can push the engine and how the game performs.

There were no follow-ups. What's interesting is less the result than how Claude got there, because it worked through the problem the way a developer would:

It went shopping for art. It checked Poly Haven, Kenney, Quaternius, Poly Pizza and OpenGameArt, settled on Quaternius's free CC0 packs, and scripted the downloads from itch.io itself.
It looked before it built. It wrote throwaway Godot scripts that loaded the kits headlessly, dumped their structure, and laid the pieces and characters out into contact sheets, so it knew how the walls, roofs, outfits and animation clips actually fit together.
It ran the game, not just the compiler. It built a benchmark into the game, ran it, saw that a big crowd was the bottleneck, fixed it, and measured again.
It tested its own work. It added an autopilot that runs the player over the bridge and up the castle road, jumping as it goes, so it could check the physics without anyone at the keyboard.
It wrote the documentation. The README covers the controls, the benchmark numbers, the architecture and the asset credits.

Over the hour that came to about a hundred shell commands and 28 files written. Everything below is a description of what it made.

Almost nothing is hand-placed

Nearly everything is generated at startup from a seed, so the town comes out the same every run and builds in about 2.5 seconds. main.tscn holds only the environment, the sun, the player, the camera and a few managers. The one hand-designed part is the layout: the river's course, the roads, the two bridges, the square, the castle mound and the pasture.

From there it's built in passes. The terrain is a 400 m heightmap on a 1 m grid, shaped by rolling hills, a ring of hills around the valley, the castle mound, the river channel, smoothed roads, a level square and flat pads for buildings. It ends up as 100 mesh chunks, a HeightMapShape3D for collision, and a mask texture the terrain shader uses to paint cobbles, dirt, paving and muddy banks. Steep slopes turn to rock.

The houses are assembled from the modular pieces of Quaternius's Medieval Village MegaKit: one to three storeys of stone, plaster or timber-frame walls on a 2 m grid, with windows, shutters, a door, corner posts, a tiled roof with the gables facing the street, and sometimes a chimney. The town builder walks along each road and places houses on both sides wherever they fit, flattens a pad for each one, and adds barrels, flowers, ivy and a lantern by the door. Roof, plaster and wood colors vary from house to house.

Twenty thousand pieces, a few thousand draw calls

Building houses out of kit pieces means a lot of pieces: about 20,000 walls, roofs, trees, props and flowers. Drawn as separate nodes, that's at least a draw call each. Instead, Claude wrote a batcher that groups every placed copy by mesh and by 32 m chunk, then turns each group into one MultiMeshInstance3D:

town/town_batcher.gd

func add(scene_path: String, xf: Transform3D, category := Category.STRUCTURE, variant := 0) -> void:
	var chunk := Vector2i(floori(xf.origin.x / CHUNK_SIZE), floori(xf.origin.z / CHUNK_SIZE))
	for entry in meshes_of(scene_path):
		var mesh: Mesh = entry[0]
		if variant != 0:
			mesh = _variant_mesh(mesh, variant)
		var key := "%d,%d:%d:%d" % [chunk.x, chunk.y, mesh.get_instance_id(), category]
		if not _groups.has(key):
			_groups[key] = {"mesh": mesh, "category": category, "transforms": []}
		_groups[key]["transforms"].append(xf * (entry[1] as Transform3D))
		instance_count += 1

Chunking keeps frustum culling working, since a whole town in one multimesh would never be off screen. The different roof and plaster colors become mesh variants that share vertex data, so tinting a house doesn't break its batch. Small things get a category that turns off their shadows and fades them out with distance: props at 140 m, flowers at 70 m.

Collision skips the scene tree as well. Houses, trees, props and fences go straight to the physics server as about 2,200 shapes on a single body.

The bridge is real geometry

I asked for a curved bridge that bends upward, mostly to see how the engine handles elevation. Claude didn't fake it with a model and a hidden ramp. Both bridges are procedural meshes with an arched cobbled deck (the main bridge rises 4 m), spandrel walls down to an elliptical arch, and parapets, all in the kit's own stone materials so they match the houses. The deck has exact trimesh collision, so the hump in the middle comes from the physics engine. The player is a CharacterBody3D, so the slopes, the bridge deck and every wall are handled the same way.

That shot came from Claude's autopilot. Set GODOTTOWN_AUTOPILOT=1 and the bot runs the player from the square over the bridge, and GODOTTOWN_SHOTS=4,7,10 saves screenshots at those times.

The jump got the same attention. It's buffered, it has a little coyote time (it still works 0.12 seconds after you run off an edge), it uses the animation library's start, loop and landing clips, and in the river you swim instead.

The crowd is what costs

I also asked to see how hard the engine could be pushed, so Claude built a benchmark: B runs a 50-second camera flight over the square, the main street, the bridge, the castle and the river, with vsync off. Here are its numbers at 1600×900 on an RTX 5070:

Setup	Average	1% low	Draw calls
Default: SSAO, 8K soft shadows, 4× MSAA, 60 walkers	188 FPS	135 FPS	~4,600
Default + 400 walking villagers	134 FPS	84 FPS	~6,300
Everything: + SSIL, SDFGI, volumetric fog, dense grass, 400 walkers	122 FPS	80 FPS	~6,500

The GPU sits around 5 to 6 ms in all three. When Claude first ran the benchmark with 400 villagers, it got 77 FPS, and the time was going to the CPU, not the GPU. Moving a villager turned out to be expensive, because each new transform ripples through a skeleton and a dozen skinned meshes (a villager is an outfit, a head, hair and eyebrows, all skinned to one skeleton). So it added an update LOD: villagers further from the camera move and animate less often, and catch up on the time they skipped when they do:

characters/villager.gd

## Distance (m) -> update the skeleton every this many frames.
const LOD_TIERS := [[25.0, 1], [50.0, 2], [90.0, 4], [INF, 8]]

characters/villager.gd

	if _frame % every != 0:
		return
	var step := minf(_pending_delta, 0.5)
	_pending_delta = 0.0
	if mode == Mode.WALK:
		_walk(step)
	visible = distance < HIDE_DISTANCE
	if visible and (on_screen or not Population.animation_lod):
		model.animation.advance(step)

Villagers off screen only update every tenth frame and don't animate at all. That took 400 villagers from 77 FPS to 134. The 9 key turns it off and on, so you can watch the difference live.

The villagers walk a graph made from the roads, the square crossings and the bridges, each keeping to their own side of the street and now and then stopping for a chat. Others stand talking in groups in the square or sit on its benches.

The chickens are generated, not downloaded

My prompt asked whether Claude could create its own 3D models, rigged and animated. Its answer was the chickens. Every other creature in the town comes from an asset pack, but there were no chickens in it, so Claude wrote tools/make_chicken.gd. The script builds a low-poly mesh from ellipsoids, cones and cylinders, skins it to a 13-bone skeleton, keys four animations (Idle with head turns, Walk with the head-bob, Peck, and a flapping hop), and exports the result as glTF:

tools/make_chicken.gd

const BONES := [
	# name, parent, rest position relative to the parent
	["root", -1, Vector3(0, 0, 0)],
	["body", 0, Vector3(0, 0.27, 0)],
	["neck", 1, Vector3(0, 0.07, 0.07)],
	["head", 2, Vector3(0, 0.12, 0.03)],
	["tail", 1, Vector3(0, 0.05, -0.12)],
	["wing_l", 1, Vector3(0.1, 0.03, 0)],
	["wing_r", 1, Vector3(-0.1, 0.03, 0)],
	["thigh_l", 1, Vector3(0.05, -0.05, 0)],
	["shin_l", 7, Vector3(0, -0.1, 0.01)],
	["foot_l", 8, Vector3(0, -0.1, 0)],
	["thigh_r", 1, Vector3(-0.05, -0.05, 0)],
	["shin_r", 10, Vector3(0, -0.1, 0.01)],
	["foot_r", 11, Vector3(0, -0.1, 0)],
]

It runs as a headless Godot script (godot --path . -s res://tools/make_chicken.gd) and writes a white and a brown chicken. The files import like any other model, in Godot or in Blender. The chickens scratch around near some of the front doors, the cows, horses, sheep, pigs and llamas live in the pasture, and a pug follows you everywhere.

Knobs for everything

Since the point was to test the engine, Claude put almost every expensive feature on a key.

Rendering toggles. 1 to 4 switch SSAO, SSIL, SDFGI and volumetric fog. 5 and 6 cycle shadow quality and grass density, 0 cycles MSAA, R cycles the render scale with FSR2, and V toggles vsync. Grass density changes how many of each chunk's instances are drawn, so changing it doesn't rebuild anything.

More villagers. 7 and 8 add or remove 50 walkers, up to 800.

Time of day. T steps through morning, noon, golden hour and night. At night the lanterns by the doors light up, all 144 of them.

Push it. P turns on SSAO, SSIL, SDFGI, volumetric fog, dense grass and 400 villagers at once.

A HUD that counts. It shows FPS and frame, CPU and GPU times, draw calls, objects and triangles drawn, plus what's in the world, the player's altitude and the height of your last jump.

What it doesn't do (yet)

There's no game. No goals, no quests, no one to talk to. You explore, and that's it. That's what I asked for, but it's worth saying.
There's no sound.
The sheep, pigs and llamas only came with idle and jump animations, so they hop everywhere.
It's the same town every time. The seed is an exported variable in the editor, not something you can change from the game.
There's no export preset, so it runs from Godot itself, not as a standalone executable.

What this says about AI

Game development is a lot more than code. There's art to find and license, kits whose pieces you have to figure out, physics to tune, animation clips to wire up and performance to measure. In this project Claude handled all of it, and when something was slow it found out why and fixed it, the same loop I'd go through myself. My part was one paragraph and a reference picture.

The town isn't a finished game, and I wasn't asking for one. But a playable, benchmarked 3D world from one prompt and an hour of waiting says a lot about where these tools are now. They're no longer limited to finishing a function for you. They can take on whole projects, and that includes game engines.

Running it

The whole project is here: godot-town.zip (289 MB). It's exactly what Claude produced, art included, minus Godot's import cache. Unzip it and run it with Godot 4.7:

cd GodotTown
godot --path .        # play
godot -e --path .     # open the editor

The first launch imports the assets, which takes about a minute. After that the town builds in about 2.5 seconds. Left-click to capture the mouse, WASD to move, Space to jump, and F1 shows the help.

All the art except the chickens, terrain, bridges, castle, grass, water, sky and mountains comes from Quaternius's free packs, which are CC0 (public domain): the Medieval Village, Stylized Nature and Fantasy Props MegaKits, the modular fantasy outfits and base characters, the Universal Animation Library and the farm animals. They're a big part of why a town like this is possible in an hour. If you use them, consider supporting Quaternius.

Markdownia: a Markdown reader with no browser inside

2026-10-16T12:00:00Z

Most Markdown apps are a web browser in a trench coat. The editor is a text box, the preview is an embedded Chromium or WebKit view, and the typography is whatever CSS the author wrote that afternoon. It's the sensible design, and it works. I wanted to see what happens if you don't do that.

Markdownia (Markdown + Avalonia; the name was too good to pass up) is a Markdown editor and viewer built with .NET 10 and Avalonia 12. You write on the left and read on the right, and Ctrl+\ collapses the editor so it becomes a plain reader. There is no web view anywhere. Every paragraph, table, callout, formula and code block in the preview is a real Avalonia control.

Markdig in, controls out

Parsing is handled by Markdig, which already covers GitHub Flavored Markdown and a good share of Pandoc's extensions. The interesting half is the other one: a renderer that walks Markdig's syntax tree and builds controls instead of HTML. Paragraphs become selectable rich-text blocks. Lists, tables, GitHub alerts, Pandoc fenced divs, figures and footnotes become composed layout panels. Math is typeset natively by CSharpMath in Latin Modern Math, and inline formulas report their baseline, so $ax^2$ sits on the line with the words around it instead of floating above them.

Parsing runs on a background thread and each render is tagged with a version number, so a burst of typing only ever paints the latest text. And if the renderer throws, the exception appears in place of the preview instead of taking down the editor and your unsaved document with it.

Typography is the point

The whole reason to skip the browser is control over how text looks. Markdownia bundles Literata, Source Serif 4, Atkinson Hyperlegible, Inter and JetBrains Mono, keeps lines to a readable measure (narrow, medium, wide or full), and offers Smooth, Sharp or Subpixel text rendering. Smart punctuation turns straight quotes into curly ones and -- into dashes. Code fonts have their ligatures turned off, because => should look like the two characters you typed.

The detail I'm proudest of is line height. Every line height is rounded to a whole pixel and the preview snaps baselines to the pixel grid, so text stays crisp instead of smearing across two rows of pixels. That exposed a quirk. When a heading's line height is tighter than the font's ascent plus descent, Avalonia keeps the baseline at the full ascent and lets the descenders hang out of the bottom of the control. The fix borrows CSS's idea of half-leading:

MarkdownRenderer.cs

// When the line height is smaller than the font's ascent + descent (headings, titles), Avalonia keeps the
// baseline at the full ascent and the descenders hang below the control. Center the glyphs in the line box
// instead, like CSS half-leading.
var overflow = _glyphExtent * fontSize - lineHeight;
if (overflow > 1)
    text.RenderTransform = new TranslateTransform(0, -Math.Round(overflow / 2));

There are nine themes: Paper, GitHub Light, Sepia and Solarized Light, plus GitHub Dark, Nord, One Dark, Solarized Dark and Dracula. Each one colors the window chrome, the editor, the preview and the code together, so switching themes repaints the whole room, not just the page.

A ribbon, unironically

The toolbar is a Word-style ribbon with Home, Insert, Design and View tabs, a Styles gallery, a hover-grid table picker and a theme gallery. A ribbon is an odd choice for Markdown, a format that exists so you don't need a toolbar. But Markdown has picked up a lot of syntax nobody remembers: footnotes, definition lists, {width=50%} attributes, *[HTML]: abbreviations, ::: warning blocks. A ribbon is a good place to discover it. Every button writes ordinary Markdown into the editor, and the file stays yours.

Two editing features turned out to be more fun than I expected.

Images resize in the preview. Hover over an image, drag the handle in its corner, and the new width is written back to the Markdown as {width=480} (or as a width attribute on an <img> tag). Writing from the preview back into the source can corrupt a document if the source has changed in the meantime, so each resize request carries the exact text it was rendered from and is dropped if that text no longer matches:

MainWindow.axaml.cs

// Ignore the request if the text has changed since this preview was rendered.
if (resize.End > doc.TextLength || doc.GetText(resize.Start, resize.End - resize.Start) != resize.Original)
    return;

Scroll sync without the feedback loop. Synchronized panes have a classic bug: the editor scrolls the preview, which scrolls the editor, which scrolls the preview. Markdownia tracks a leader instead. Whichever pane you last pointed at, clicked, scrolled or typed in is in charge, and the other one only follows.

MainWindow.axaml.cs

// Scroll sync follows whichever pane the user is working in, so the panes never drive each other in a loop.
void Lead(Control pane, ScrollLeader leader)
{
    pane.AddHandler(PointerEnteredEvent, (_, _) => _scrollLeader = leader, handledEventsToo: true);
    pane.AddHandler(PointerPressedEvent, (_, _) => _scrollLeader = leader, RoutingStrategies.Tunnel, handledEventsToo: true);
    pane.AddHandler(PointerWheelChangedEvent, (_, _) => _scrollLeader = leader, RoutingStrategies.Tunnel, handledEventsToo: true);
    pane.AddHandler(KeyDownEvent, (_, _) => _scrollLeader = leader, RoutingStrategies.Tunnel, handledEventsToo: true);
}

One native executable

Like webshare, Markdownia publishes with Native AOT, and that shaped a lot of decisions: compiled XAML bindings, source-generated JSON and regexes, editor highlighting rules built in code instead of loaded from XSHD files, and no reflection-based view location. Syntax highlighting for the preview's code blocks comes from a small hand-written tokenizer that covers about 25 languages, from C# and Rust to Dockerfile and Lua. It's deliberately approximate: pleasant, readable coloring with no regex engine, grammar files or reflection. dotnet publish finishes with zero trim or AOT warnings.

The result is a single Markdownia executable of about 36 MB, fonts included, with the Skia and HarfBuzz native libraries next to it. It starts like a native app because it is one.

Two helpers make a GUI app easier to check without clicking around:

Markdownia --smoke-test out.png renders the main window and the full preview offscreen, saves both as PNGs, and exits with status 0 if everything worked. It's a quick way to confirm an AOT build really runs.
tools/Snapshot renders the real window headlessly in any theme, layout or scroll position. The Nord screenshot above came from it.

On Linux, packaging/linux/build-deb.sh builds a .deb that installs a markdownia command, a desktop entry and icons, and registers Markdownia for text/markdown, so it shows up under “Open With” for .md files. It needs glibc 2.38 or newer (Ubuntu 24.04, Debian 13 or later).

What it doesn't do (yet)

SVG images aren't rendered; you get their alt text.
Raw HTML blocks are reduced to their text and images, though common inline tags like <kbd>, <sup> and <mark> work.
Pandoc features Markdig doesn't implement (inline notes, citations, line blocks, example lists) aren't available.
You can select text within one paragraph, list item or code block at a time, but not across several. This is the real price of skipping the browser: a web view gives you document-wide selection for free, and a stack of native controls doesn't.

Try it

Version 1.0.0 is on the releases page as a .deb and a Linux x64 zip. To build it yourself you need the .NET 10 SDK:

git clone https://github.com/dotericr/Markdownia
cd Markdownia
dotnet run --project src/Markdownia -- README.md

It's MIT licensed, and the code is on GitHub. Point it at a README you've read a hundred times and see how it looks with real typography.

webshare: one command to hand a file across the room

2026-09-26T12:00:00Z

Every so often I need to move a file from the machine in front of me to a device that's right there. A phone on the couch, a laptop on the kitchen table, a Windows box in the other room. The options are all a little annoying. Cloud drives round-trip my file through someone else's data center to travel eight feet. USB sticks are never where I left them. Setting up a Samba share for one ISO feels like building a bridge to cross a puddle.

What I actually want is the old python -m http.server trick, but polished. It should work on a single file, pick its own port, tell me the address to type, look decent on a phone, and go away on its own when I forget about it.

So I wrote webshare.

webshare ~/Downloads/firmware-2.4.1.bin
webshare --time 15 ~/Pictures/vacation
sudo webshare --open-firewall --port 8080 ./build

Run it with a file or a folder and it starts a temporary web server, prints the local and network URLs, and waits. Folders get a browsable listing. A single file gets a landing page with one big download button. By default the share shuts itself off after 60 minutes (--time 0 if you really want it to run forever).

Small, but not careless

It's a small tool, but anything that serves files to a network deserves some paranoia. A few decisions I'm happy with:

Paths can't escape the share. Every request path is split into segments, any . or .. is rejected outright, and then the canonical result has to still live under the root:

Program.cs

// Reject traversal segments and verify the canonical target remains under the root.
if (segments.Any(segment => segment is "." or ".."))
{
    targetPath = string.Empty;
    return false;
}

targetPath = Path.GetFullPath(Path.Combine(rootPath, Path.Combine(segments)));
var comparison = OperatingSystem.IsWindows()
    ? StringComparison.OrdinalIgnoreCase
    : StringComparison.Ordinal;

Symlinks are ignored. Every component of a requested path is checked for a reparse point (a symlink, or a junction on Windows). A link inside the shared folder that points at /etc is neither listed nor served.

Strict headers everywhere. Every response gets Cache-Control: no-store, nosniff, no-referrer, and a Content Security Policy that only allows inline styles. The pages have no JavaScript and nothing to inject into.

No authentication, stated plainly. Anyone who can reach the port can download what you're sharing. The README says so, and the tool is meant for a trusted network. I'd rather be honest about that than bolt on a password prompt that gives a false sense of safety.

The firewall problem

The most common way a LAN share fails isn't a bug. The firewall on the sharing machine silently drops every connection from another device, and the server can't reliably detect that from its own side. The only real test is another device trying to connect.

So --open-firewall adds a temporary, narrowly scoped exception and removes it on exit:

On Windows, it's a netsh rule limited to the Private profile and LocalSubnet.
On Linux, it adds iptables/ip6tables rules for each active local subnet it can find.

Both need elevation, and on Linux that means sudo runs the whole app as root, which I don't love and the docs spell out. A normal exit or Ctrl+C removes the rules. A power cut doesn't, so every rule is named webshare-<guid> (as an iptables comment on Linux) to make leftovers easy to find and delete by hand.

Why .NET for a tiny tool?

Honestly, because it keeps getting better at small things. WebApplication.CreateSlimBuilder gives me Kestrel with almost nothing else. The stylesheet is an embedded resource, so there's no asset folder to lose, and the whole thing publishes as a Native AOT single binary for Linux x64 and Windows x64. It starts instantly and has no runtime to install on the machine that's sharing.

make publish-linux && sudo make install
webshare .

That's the whole pitch: one command, a URL, and it cleans up after itself. The code is on GitHub if you want the same thing.

Teaching Linux to speak passkey, in C#

2026-09-22T12:00:00Z

Passkeys are great on phones and Macs. On a Linux desktop the story is thinner: you can use a hardware security key, but the laptop's own TPM (the chip that exists precisely to guard keys) usually just sits there.

Then I found passkeyd, an opinionated Linux WebAuthn authenticator written in Rust. It pretends to be a USB security key, so every browser that supports hardware keys “just works,” and it keeps the credentials behind the TPM. It's a clever design, and I wanted to understand it all the way down. For me the best way to learn someone else's code has always been to port it, so cspasskeyd is a staged C#/.NET 10 port. The Rust original stays untouched.

Pretending to be a USB key

The trick at the center is /dev/uhid, the Linux interface that lets a user-space program create a virtual HID device. The daemon registers something that looks like a FIDO security key. The browser finds it, and from then on they talk CTAPHID over HID reports.

Stage one covers exactly what's needed for a real registration and sign-in:

CTAPHID INIT, PING, and CANCEL
CTAP2 GetInfo, MakeCredential, and GetAssertion
Keepalives while waiting on the user, and cancellation that actually cancels

CTAP2 requests run off the HID reader thread, one operation at a time per device. That sounds obvious, but getting it wrong is how you end up with a browser spinner that never stops.

Keys that never leave the chip

Every credential is an ES256 (P-256) key created inside the TPM, under a deterministic storage primary that's created for each operation and then flushed. There are no persistent TPM handles to leak. The C# side talks to the system TSS2 libraries through a small native C shim. It asks for a signature over a 32-byte SHA-256 digest and gets back the DER-encoded ECDSA signature WebAuthn expects.

The rule I care most about: if there's no TPM, it fails. There is no quiet fallback to software keys. A security tool that silently downgrades itself is worse than one that refuses to run.

Approval, not decoration

Every registration and every sign-in needs a fresh local approval. The root daemon doesn't draw UI. It launches a tiny, separate GTK4 prompt in the desktop user's session, and that prompt refuses to run as root. The two processes speak a deliberately boring, length-bounded binary protocol:

PIN prompt frame protocol

request:   "CPPR" | version 1 | u16 rp_len | u16 account_len | rp_id | account
response:  "CPRS" | version 1 | status (1 submitted, 2 cancelled) | u16 pin_len | pin

The prompt only collects the PIN. It doesn't decide anything. The daemon checks the PIN through PAM, using a dedicated cspasskeyd-pin service, so the machine's own authentication rules stay in charge. Relying-party names are validated and shown as plain lowercase labels. Account text is stripped of control and bidi characters so a hostile site can't dress up the dialog. And the prompt never fetches user.icon URLs: a site doesn't get to make my authenticator load a remote image.

Porting as a way of reading

The most valuable part so far hasn't been the code. It's the SECURITY.md that came out of reading the original line by line: findings I checked, mitigations the port must carry, and things that are explicitly out of scope, like the CTAP ClientPIN and extensions. Port, audit, and write it down turns out to be a very good way to learn a protocol.

Next up is the moment of truth: validating a live registration and sign-in in Edge against real TPM hardware and the real PAM stack, which the unit tests deliberately fake. After that comes stage two, with the enrollment UI, a manager, migration tooling, and packaging. Watching a browser say “use your security key” and knowing the key is my laptop's own TPM is the finish line I'm aiming for.

LinuxPass: the KeePass window I kept missing

2026-09-17T12:00:00Z

I've kept my passwords in a KeePass database for a very long time. On Windows, KeePass 2.x is a comfortable old chair: a menu bar, a toolbar, groups in a tree on the left, entries on the right, details at the bottom. It isn't pretty, but my hands know exactly where everything is.

On Linux I've mostly used KeePassXC, and it's excellent. But this week of passkey work (more on that in the next post) had me thinking about how a password manager and an authenticator could share one database. I wanted a codebase I understand end to end, in the language I use every day. So I started LinuxPass: a cross-platform Avalonia app on .NET 10, laid out like the KeePass I remember.

What it does today

It's deliberately modest so far, and everything it does, it does against my real database:

Opens and unlocks KeePass .kdbx files, and legacy .kdb files too, with a master password
Shows nested groups as a tree and the entries in a sortable list
Searches titles, usernames, URLs, and notes all at once
Edits username, password, URL, and notes in place, then saves back to the same file
Copies a password from the detail panel or a right-click menu
Has an A–Z index for jumping around a long entry list
Locks the database and clears the decrypted data out of the view model
Remembers the last database and window size, and asks for the master password on launch

The file format work is handled by KeePassLib.Standard, a .NET Standard build of the same library KeePass itself uses. That was a big reason to try this at all. I'm not reimplementing the KDBX crypto; I'm building a UI around a library that has read and written these files for years.

MVVM, the Avalonia way

The app is a straightforward Avalonia MVVM layout: a MainWindow with its MainViewModel, and a separate password prompt window. What surprised me is how easy the “classic desktop app” look is in Avalonia. A TreeView, a DataGrid, a GridSplitter or two, and a proper menu bar give you something that looks like it belongs to the late-2000s Windows era in the best way. It behaves the same on Windows and on my Linux desktop.

Where it's headed: talking to the browser

The part I'm most excited about is still a design doc. The KeePassXC-Browser extension talks to its desktop app over browser native messaging. If LinuxPass speaks that same protocol, I can reuse the existing extension instead of writing my own:

docs/PluginProtocol.md

KeePassXC-Browser extension
             │  Browser Native Messaging
             ▼
      linuxpass-proxy
             │  Unix-domain socket
             ▼
      LinuxPass desktop process
             │
       ┌─────┴─────┐
       ▼           ▼
 Active database  Browser/passkey services

The one rule I wrote in bold: the desktop process owns the open database. The small proxy the browser launches never opens the .kdbx itself. Two processes with the same file open is how you get stale reads, lock fights, and eventually lost entries.

A password manager is a strange project for a hobbyist, because the bar is “never lose anything, ever.” That's also why it's a good one. It forces the careful habits I want everywhere else.

SmartCopy: copying files without copying history

2026-09-13T12:00:00Z

Every long-lived home network has a folder like this somewhere:

Backup/
  OldLaptop/Projects/...
  OldLaptop-2/Projects/...
  From D/Projects/...
  Sep2026/FromD/Projects/...
  Projects (copy)/...

Each copy made sense on the day it was made. Put together, they're a mess: mostly the same trees, a few genuinely different files, and timestamps that are useless because every copy tool has rewritten them at least once.

I wanted to consolidate all of it onto one big drive without making things worse. The usual tools don't quite do it. cp and robocopy happily copy the fifth identical tree. Sync tools compare against one destination path, not “does this already exist anywhere over there?” So I wrote SmartCopy.

smartcopy <source> <destination> [--ssd] [--skipdevbin]

Content, not timestamps

The rules are small and strict:

A whole directory tree is compared by relative paths, file lengths, and file contents. Timestamps and attributes are ignored, because I've learned not to trust them.
If a complete matching tree already exists anywhere in the destination, even under a different parent, it's skipped.
If a tree has changed at all, it's copied normally. Individual files inside it are never skipped just because a matching file exists somewhere else. I decided to deduplicate at the directory level so the result still looks like the folders I remember.
Large archives (anything over 100 MiB with a known extension like .zip, .7z, .iso, or .zst) are the exception. Those are compared globally, because five copies of the same 4 GB installer ISO are the whole reason the drive is full.

Copying keeps the source's top-level directory name, so smartcopy ~/Restore/Projects /mnt/archive lands in /mnt/archive/Projects instead of spraying files into the root.

Asking instead of guessing

When a different file is already sitting at the destination path, SmartCopy stops and shows both sides (name, size, last-write time) and lets me skip, overwrite, create a numbered conflict name, or cancel. The choice can apply to everything after it. If input is redirected and nobody's there to answer, an unresolved conflict is an error rather than a silent guess.

A paper trail

The destination root gets three files that make the whole run auditable:

File	What it records
`manifest.json`	Cached hashes, so re-runs don't re-read everything
`duplicates.txt`	Every directory and archive that was skipped, and what it matched
`merge_conflicts.txt`	Every conflict decision that was made

That last point matters more than it sounds. The scary part of deduplication isn't the copying, it's wondering later whether something got skipped that shouldn't have. With the paper trail I can check afterward instead of worrying.

Two small switches

--ssd turns on bounded four-way parallel hashing and copying. On spinning disks it's slower (the heads just thrash), so it's opt-in. --skipdevbin skips the bin and obj folders next to recognized .NET project files, because nobody needs build output from 2014.

The same flag, down to the -sdb shorthand, is in my backup tool PatternBuffer.NET. Small utilities and big ones keep borrowing ideas from each other around here.

Transporter Room: giving a backup tool a bridge console

2026-09-08T12:00:00Z

In my last post I wrote about PatternBuffer.NET, my Borg-inspired backup engine and its beam command. The CLI is how I build backups. But the backups I actually run are the ones that are pleasant to start, and a terminal full of flags isn't that. Backups need a big friendly button.

So beam got a control room.

A console, not a form

Transporter Room is an Avalonia desktop app, and I leaned into the theme on purpose. Instead of a gray dialog with a progress bar, you get a layered hull, illuminated “archive chambers,” console lights, and an amber-and-cyan status deck. All of it is drawn with Avalonia vector composition, with no bitmap assets, so it scales cleanly with the window.

The centerpiece is the status beam: a custom-drawn transporter effect with a rising particle shimmer and a vertical “materialization field” that gets brighter as beam reports progress. It's silly, and it's also genuinely useful. You can read the state of a backup from across the room.

A few practical decisions under the theming:

The BACKUP NOW command deck is fixed directly above the status area. The repository, archive, and source panels scroll on their own, so the button never scrolls away.
The archive name is optional. Leave it blank and beam generates a stardate name like stardate-2026.68.
A FILTERS library has exclusion presets for .NET and Visual Studio output, Node, Python, JVM, Rust, Go, logs, and OS clutter, plus a box for hand-written globs. Each selection becomes an --exclude argument.
A circular ? button opens an operator's manual, because the stardate format and filters deserve an explanation somewhere.

Keeping the engine separate

The most important design decision isn't visible at all. Transporter Room doesn't contain a backup engine. It launches beam and talks to it over a versioned JSON protocol: capabilities, progress, and results all come back as structured messages instead of scraped console text.

That boundary means the CLI stays the single source of truth. Anything the GUI can do, I can script, and a GUI bug can't corrupt a repository. It also made the second front end easy.

The web sibling

Transporter Room .NET is an ASP.NET Core 10 Blazor Server dashboard for the machine that holds the repositories. It has a first-run setup flow, administrator and user accounts, host telemetry (CPU, memory, storage), deduplication and compression stats, and archive history per repository. It builds a client inventory from the host and OS metadata stored in each archive, and it generates copyable beam up, beam list, and beam down commands for any client.

It has one rule I'm strict about: the dashboard observes; it never starts a backup. It runs beam info and beam list for telemetry, and beam init only when an authenticated user creates a repository. Scheduling stays on the clients where it belongs. A web page that can quietly kick off backups on every machine in the house is a web page that will eventually do it at the worst possible moment.

Passphrases for encrypted repositories are passed to beam once during initialization and never stored. The dashboard simply reports those repositories as locked. I'm fine with that trade.

Make it useful, then make it fun to use. The fun part is why I actually press the button.

PatternBuffer.NET: beam up the bytes that matter

2026-09-04T12:00:00Z

I've used Borg Backup for years, and I've admired its design for just as long. It splits files into content-defined chunks, stores each unique chunk once across every snapshot, and compresses everything. It's elegant. I also mostly live on Windows and .NET, where Borg is a bit awkward. So I did the thing every programmer eventually does with a tool they love: I wrote my own.

PatternBuffer.NET is an independent, cross-platform backup CLI for .NET 10. The command is beam, and the verbs are what you'd expect from a transporter:

beam init  ssh://eric@nas/var/lib/beam/repo --encryption=passphrase
beam up    ~/Projects --repository ssh://eric@nas/var/lib/beam/repo -sdb
beam list  --repository ssh://eric@nas/var/lib/beam/repo
beam down  stardate-2026.67 ~/restore --repository ssh://eric@nas/var/lib/beam/repo

(Yes, the Star Trek Borg theme is intentional. Every archive joins the repository's collective, and unchanged data is assimilated only once.)

To be clear, it's not Borg. It doesn't read Borg repositories, isn't compatible with them, and isn't affiliated with the project. It borrows ideas, not formats. It even got a logo, because a backup tool with a transporter theme deserves one:

Chunks that survive an insert

Fixed-size chunking breaks down the moment you insert a byte near the start of a file: every block after it shifts, and deduplication falls apart. Content-defined chunking puts boundaries where the data says to, so an insert only disturbs the chunks around it.

beam uses FastCDC with a seeded Gear table. The heart of it is a rolling hash that's one shift and one add per byte:

Chunking.cs

hash = (hash << 1) + gear[value];
if (length >= minimum && ((hash & mask) == 0 || length >= maximum))
{
    // cut here: this byte ends the chunk
}

The Gear table is generated from a per-repository seed with a SplitMix-style mixer. Chunk boundaries are stable within one repository but differ between repositories, which avoids leaking chunk-size patterns across them.

The rules I wrote before the code

The architecture doc opens with a list of principles, and the first is the one everything else hangs on: a backup program must never present a partially committed archive as complete. Some of the others:

Stored data is immutable. Packs, index fragments, and archive records are written once and replaced, never edited in place.
Every on-disk format is versioned, with a defined upgrade or rejection path.
Memory is bounded. Parallel compression is limited by a memory budget, not just the CPU count.
No silent metadata loss. Metadata the platform can't store produces a warning or a failure, according to an explicit policy.

Compression is always zstd level 3. Encryption is opt-in AES-256-GCM with a passphrase. Every chunk is compressed independently, so the pipeline can do that work in parallel.

Remotes over plain SSH

The first remote backend needs nothing on the server except SSH. beam scans and chunks locally, takes a lock over SSH, uploads new packs and index fragments with SCP, and publishes the archive record last. That record is the commit point, so a dropped connection leaves orphaned packs that compact can clean up, never a half-archive that list would show you. A remote down fetches only the packs the selected archive references.

A future version will run a persistent protocol through SSH for batching, range reads, and resumable uploads. The design leaves room for it without needing it yet.

Stardates

Archives you don't name get one automatically:

BackupService.cs

var fraction = Math.Floor(local.DayOfYear / (double)daysInYear * 100) / 100;
return (local.Year + fraction).ToString("F2", CultureInfo.InvariantCulture);

It's the “Kelvin timeline” style of stardate: the year plus the fraction of it that's gone by. So stardate-2026.67 is early September. It sorts correctly and reads well in a list. I'll admit it's also just fun.

Next up: a command line is great for building a backup tool, but it's not what makes people run backups. That's the next post.

A Jellyfin-to-AV1 production line

2026-08-30T12:00:00Z

Media libraries only grow. Mine lives on a Jellyfin server, and a lot of it was encoded years ago in whatever codec the ripper defaulted to at the time. AV1 can cut that down dramatically at the same visual quality, and modern Intel GPUs can encode it in hardware. The math was obvious. The logistics weren't: thousands of files, a server I didn't want to hammer, and a job that would take weeks and had to survive every interruption.

I split it into two small programs connected by the humblest interface there is, a text file.

Step one: write down what exists

jfdownload walks the Jellyfin library and writes an index. Movies are one line each. Shows are a title, indented seasons, and further-indented episodes, with | separating the fields:

MediaIndex.txt

101 Dalmatians (1996)|https://…/Items/e255…/Download
12 Monkeys
  Season 1
    Episode 1|Splinter|https://…/Items/ad09…/Download
    Episode 2|Mentally Divergent|https://…/Items/1af2…/Download

That looks almost too simple. It's the best decision in the project. I can read it, grep it, sort it, delete lines from it, or hand-edit it to process one show first. The indexer doesn't need to know anything about encoding, and the encoder doesn't need to know anything about Jellyfin's API. When something goes wrong, I open a text file instead of a debugger.

Step two: the production line

MediaProcessor reads the index and handles one item at a time:

Download the movie or episode from Jellyfin.
Check it with ffprobe. If it's already AV1, skip the encode.
Otherwise, encode it with hardware-accelerated ffmpeg on Intel Quick Sync, keeping the original container (.mkv stays .mkv, .mp4 stays .mp4).
Upload the result into an organized movie or Show/Season N folder.
Clean up the temporary files, record progress, and move on.

The hardware path is set up explicitly so frames stay on the GPU from decode to encode:

ffmpeg -init_hw_device qsv=qs -hwaccel qsv -hwaccel_output_format qsv \
       -i input.mkv -c:v av1_qsv … output.mkv

Built to be interrupted

Batch jobs that run for weeks need to be defensive, not clever. Before starting, MediaProcessor loads an inventory of what's already on the destination server, and anything already there is marked “Already on server” and skipped. That means there's no separate progress file to get out of sync: the output is the checkpoint, and restarting after a crash just continues.

It keeps going past individual failures: one corrupt episode is logged as a non-fatal error rather than ending the run at 3 a.m. And it overlaps the slow parts. While one item is encoding, the next one is already downloading, which keeps both the network and the GPU busy:

MediaProcessing.cs

PreparedMediaItem? currentItem = await currentPreparationTask!;
currentPreparationTask = index + 1 < items.Count
    ? PrepareItemAsync(items[index + 1], sessionRoot, progress, token)
    : null;

await ProcessPreparedItemAsync(currentItem, progress, token);

It has a plain Start/Stop UI with progress bars for download, encode, and upload, and the per-run temp folder is deleted however the run ends.

There's a commented-out vpp_qsv line in the source for denoising and downscaling to 720p. It's evidence of an evening spent convincing myself that I wanted to shrink the files, not the picture.

The part I'd reuse everywhere

Whenever a job has a discovery phase and a doing phase, I now reach for a plain intermediate file between them. It turns one big fragile program into two small, testable ones, and it gives me a place to step in by hand. It's the same staged thinking that shaped my earlier disc-ripping pipeline, just with fewer moving parts.

From shiny discs to a searchable library

2026-08-26T12:00:00Z

Somewhere in the house is a shelf, then a closet, then a few plastic tubs of DVDs. Ripping them isn't hard. HandBrake has made that easy for a long time. The hard part is the other 90% of the job: noticing a disc is in the drive, figuring out which movie it actually is, naming the file so the media server recognizes it, not ripping something that's already in the collection, getting it onto the server, and cleaning up. Do that by hand two hundred times and you'll write a program too.

A pipeline of small components

The Windows app, DvdRipperGUI, is a set of small components that never call each other directly. They communicate over an in-process message bus, plus a request/response bus for when one component needs an answer from another. The message list reads like a checklist of the job:

Messages.cs (a sampling)

LookForDVD   FindTitle   AskForTitle   CreateFilename   CheckExists
StartRipDVD  UploadFile  CleanupFile   ManualUpload     StatusUpdate

DvdDetector waits for a disc and announces it.
LocalTitleSearch looks up the title with TMDB, and AskForTitle pops up a dialog when the disc label is something useless like DVD_VIDEO. There are a lot of those.
FileNamer turns the chosen title into Title (Year).mp4, the format media servers match on the first try.
CheckInCollection asks the server whether that movie already exists before anything gets ripped.
HandbrakeInterface drives HandBrakeCLI and reports progress.
FileUploader and FileCleanup finish the job, and a RetryForm handles the uploads that don't.

Keeping everything on a message bus made the steps easy to reorder, skip, and test on their own. It also made a log window nearly free: every message is already a line of history.

The server side

DvdRipperServer is a tiny ASP.NET minimal API next to the movie folder. /movie?movieName=…&year=… answers "do we already have it?", /movies renders the whole collection as an HTML table (with a regex that also understands {tmdb-…} tags in names), and /upload receives the finished file. A separate worker service, DvdServerFilesystem, handles the file-management side on the server.

The /movie endpoint answers “yes” with 302 Found and “no” with 404. I'm not going to defend that choice of status codes, but it works.

The day the source went missing

This is the part I'm least proud of and most amused by. At some point the best copy of DvdRipperGUI I had was a compiled build sitting on a desktop, not the project that produced it.

So I pointed a .NET decompiler at my own DLL. .NET assemblies keep a lot of structure, so what came back was very readable. Every file in the current source still starts with a // Decompiled with JetBrains decompiler header, and I've left them there on purpose as a reminder. You can also see where the compiler got to my code first. This used to be a one-line interpolated string:

Components/FileNamer.cs, as the decompiler sees it

DefaultInterpolatedStringHandler interpolatedStringHandler = new DefaultInterpolatedStringHandler(3, 1);
interpolatedStringHandler.AppendLiteral(" (");
interpolatedStringHandler.AppendFormatted<int>(movie.Year);
interpolatedStringHandler.AppendLiteral(")");
string stringAndClear = interpolatedStringHandler.ToStringAndClear();

If you ever need an argument for good backups, that's one. It's also part of why the next experiment, DiscRipperNext, is a fresh Avalonia project instead of more patches. Its first real design decision is a LinuxDiscDetector class: put the one truly platform-specific piece (how do I know a disc was inserted?) behind its own boundary, and let everything else be portable.

The tubs are getting emptier. The library is getting better organized. And the next stage of this pipeline became its own project.

Lawn logic: a sprinkler controller from GPIO pins to my phone

2026-08-21T12:00:00Z

The sprinkler controller that came with the house had one real job and did it badly. It could run all the zones, for the same amount of time, on the days I picked. That was about it. The shady side yard doesn't need what the full-sun front lawn needs, and the controller simply had no way to express that.

The valves themselves are just 24-volt solenoids. So the controller went into a drawer. A Raspberry Pi and a GPIO relay board went into the valve box's wiring, and I started over.

The proof of concept

The first version, preserved in the docs as SimpleExample.md, is a single loop that fits on one screen:

SimpleExample.md

var controller = new GpioController();
var pins = new int[] { 21, 5, 6, 13, 16, 19, 20 };

// Turn off all the sprinkler valves
foreach (var pin in pins)
{
    controller.OpenPin(pin, PinMode.Output);
    controller.Write(pin, PinValue.High);
}

Notice that “off” is High. The relay board is active-low: pulling a pin low energizes the relay and opens the valve. That has one nice property. If the program crashes and the pins float high, the water shuts off. If you're going to get a hardware detail backwards, get it backwards in the direction that doesn't flood the yard.

Seven zones, seven BCM pins (5, 6, 13, 16, 19, 20, 21), with 26 left free on the board for an eighth someday.

The real thing

The proof of concept watered the lawn for a season. The real system is two projects.

SprinklerServer runs on the Pi and exposes a REST API. Zones get friendly names (“Front Lawn” is much nicer than “GPIO 13”). Turning one zone on turns every other zone off, so only one valve is ever open. Schedules are a set of weekdays, an ordered list of zones, a duration for each, and a start time, and several schedules can share a day. New sod, for example, gets an extra midday schedule that I delete once it's established. If I turn a zone on by hand in the middle of a scheduled run, the schedule pauses and then resumes where it left off. Hardware access sits behind an IZoneHardwareController interface, with a no-op implementation so the whole thing runs on my desktop for testing.

SprinklerApp is an Avalonia client with desktop, browser, Android, and iOS targets from one codebase. The phone is the one I actually use: standing in the yard, turning on the zone with the broken head, and watching it.

A rain sensor made of weather data

Instead of wiring in a physical rain sensor, the server asks the National Weather Service API. With the Rain Sensor setting enabled, a scheduled run is skipped if either:

measurable rain was observed in the two days before the start time, or
rain is forecast for three or more hours on the watering day.

It checks once a day, and again right before each scheduled run. A skipped run is recorded as handled for that start time, so the scheduler doesn't keep asking the same question every minute of the watering window.

Mutual TLS in the backyard

This is a device that turns physical things on and off, on my network, with an app on my phone that leaves the house. So the server requires a client certificate. Only clients holding a certificate from my own small certificate authority can talk to it, and in the other direction the app trusts the server only if its certificate chains to that same private root. It's more ceremony than a sprinkler seems to deserve, right up until you picture someone else running your zones at 3 a.m. It's baffling to me that my little sprinkler controller is more paranoid about security than some credit reporting agencies are, but this is the world we live in these days.

The drawer still has the old controller in it. It's staying there.

LOAD "ERICR.ORG",8,1

2026-08-17T12:00:00Z

My first programs were LOGO and BASIC on a TRS-80, in 1983. A couple of years later it was a Commodore 128 and RUN magazine, whose type-in listings were the best part of every issue. You typed a program in one line at a time, got the ?SYNTAX ERROR that meant you'd mistyped something, fixed it, and ran it again. When it finally worked, it felt like you'd built it yourself. I learned a lot from those pages, and from typing every character by hand. You can't skim a program you have to type.

That's roughly the spirit of this site.

Who's writing

I'm Eric. I've been building things with computers since the early '80s: BASIC and LOGO, then QuickBASIC, Turbo Pascal, Turbo C, and assembly with MASM. I spent a stretch in the demoscene writing audio code for the Gravis Ultrasound. I installed Slackware from a stack of floppies in 1993 and have run some flavor of Linux ever since. I earned a CS degree from the University of Nevada, Reno, and I've spent the decades since designing infrastructure, writing software across a lot of languages and platforms, and solving real problems for real people.

These days I mostly write C# and .NET, with a detour into VR and Unity, and lately a lot of time figuring out how to work with AI tools instead of just around them.

What to expect here

My ~/Projects folder is a museum of scratched itches: backup engines, media pipelines, a sprinkler controller, disc rippers, and plenty of small utilities that exist because something annoyed me one time too many. Most of them have never been written up anywhere. This is where that changes.

Expect articles that are:

About real projects, with the design decisions, the dead ends, and the code that matters
Honest about trade-offs, because the why is usually more useful than the what
A little bit nerdy about it, since a backup tool that names its archives with stardates is my kind of fun

The site itself is a small project too. It's a static site built by a homemade C# generator from plain Markdown files, and the illustrations are painted by an AI image model running on a server in my house. The home page is a Commodore disk directory for a reason.

HELLO.BAS

10 PRINT "HELLO FROM ERICR.ORG"
20 GOTO 10

Welcome aboard. READY.