<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom">
    <channel>
        <title>Astrohacker Blog</title>
        <link>https://astrohacker.com/blog</link>
        <description>Dispatches from the Astrohacker portfolio.</description>
        <lastBuildDate>Mon, 10 Aug 2026 12:00:00 GMT</lastBuildDate>
        <docs>https://validator.w3.org/feed/docs/rss2.html</docs>
        <generator>https://github.com/jpmonette/feed</generator>
        <language>en</language>
        <copyright>Copyright (C) 2026 Astrohacker</copyright>
        <atom:link href="https://astrohacker.com/blog/feed.rss.xml" rel="self" type="application/rss+xml"/>
        <item>
            <title><![CDATA[KeyPears Is Coming Home to Astrohacker]]></title>
            <link>https://astrohacker.com/blog/2026-08-10-keypears-coming-home-to-astrohacker</link>
            <guid isPermaLink="false">https://astrohacker.com/blog/2026-08-10-keypears-coming-home-to-astrohacker</guid>
            <pubDate>Mon, 10 Aug 2026 12:00:00 GMT</pubDate>
            <description><![CDATA[KeyPears is hybrid post-quantum federated messaging and a password manager—email-shaped addresses, self-hosted nodes, and private secret exchange for developers. It is moving into Astrohacker.]]></description>
            <content:encoded><![CDATA[
Password managers store secrets. Chat apps send messages. Email is federated
but not end-to-end encrypted in any way that helps you hand someone a database
URL without also handing it to a dozen intermediaries.

None of them do all three well: **hold secrets under your key**, **send private
messages across operators**, and **share a secret the way you share a DM**—then
let the recipient put it in *their* vault.

**KeyPears does.** It is a hybrid post-quantum federated end-to-end encrypted
messaging system and password manager. The network shape is like email. The
security baseline is built for 2026. And it is coming home under
[Astrohacker](https://astrohacker.com).

## What KeyPears is

Short version:

- **Messaging** that is end-to-end encrypted by default, with hybrid classical
  and post-quantum crypto on the normal path—not a “secure mode,” not an
  enterprise checkbox.
- **A vault** for passwords and other secrets. The node stores ciphertext. Your
  client unlocks and encrypts. The operator of a node is not supposed to read
  your logins or notes.
- **Addresses like email:** `name@domain`. You talk to people on other domains
  the way email talks to other mail servers.
- **Anyone can run a node.** The network is multi-operator by design, not a
  single company silo wearing a federation sticker.
- **Discovery and delivery** follow an email-shaped architecture: domains,
  well-known configuration, pull-style delivery between nodes—not one global
  chat host that owns every conversation.

This is what “email for 2026” means in practice: the social model people already
understand (addresses, domains, someone else’s server), without SMTP-era
plaintext and without pretending a SaaS inbox is the same thing as a protocol.

We already said the hard crypto part out loud. KeyPears went hybrid post-quantum
on the default path—every message, every signature, every account. That write-up
is still the right reference for the construction:
[KeyPears Goes Hybrid Post-Quantum](/blog/2026-04-27-keypears-hybrid-post-quantum).

## Already launched — now moving home

KeyPears is not a fresh pitch deck. It launched earlier as its own product
surface in the Astrohacker portfolio—secret exchange, messaging, identity under
one roof. See the portfolio intro and the fold-in note if you want the company
timeline:

- [Introducing Astrohacker](/blog/2026-04-13-introducing-astrohacker)
- [Folding the Portfolio into Astrohacker](/blog/2026-07-11-unifying-under-astrohacker)

What is new is not the idea. **What is new is where the work lives.**

We are bringing KeyPears into the Astrohacker home—code, product path, and
company front door at [astrohacker.com](https://astrohacker.com). Legacy labels
and older hosts can lag. Cutover is project by project. The direction is set:
KeyPears belongs under Astrohacker, not as a permanent peer brand on a product
mall homepage.

This post is a status report, not a product launch URL. No install checklist.
No “sign up here” subdomain. When something is ready to use in public, we will
say so plainly. Until then: capability and architecture first.

## The password manager half

You get a vault. Names and types for list and search. Sensitive fields—
usernames, passwords, free-form notes—live inside client-encrypted blobs. The
node can help you find “the GitHub login” without knowing the password.

That is the boring half, and boring is good. A password manager that treats
crypto as plumbing should feel ordinary: unlock, create, edit, lock.

## The messaging half

You get private channels between addresses. Messages are end-to-end encrypted
with the hybrid construction (classical and post-quantum together). Nodes
exchange ciphertext. Opening a conversation can require proof of work at the
*recipient’s* difficulty so spam is not free.

Federation is real work, not a slide. Same-domain delivery and cross-domain
delivery are both part of the product story: Alice on one operator’s node can
reach Bob on another, the way email works when two people do not share a host.

The server still sees addresses, routing metadata, and ciphertext. It does not
get a free pass into the body of the message.

## The part that matters most for developers

Passwords are table stakes. The interesting product is **secret exchange**.

Teams constantly need to pass:

- environment variables
- database URLs
- API keys
- service tokens
- other config that should never land in a public channel

Today that material travels through chat apps, email, paste sites, and “quick”
screenshares. The history is searchable forever by the wrong people. The
clipboard is a gossip protocol.

KeyPears treats a vault item as something you can **send as a private message**.
The recipient sees a secret card, not a dump of fields in chrome. They can
**save it into their own vault**, re-encrypted under *their* key, with enough
provenance to know it came from a message—without the node reading the secret
itself.

That loop—**hold → share → receive → store again under a new key**—is the
product. It is why messaging and the vault are one system, not two apps glued
together with a CSV export.

No federated system of this shape exists as a coherent product: hybrid
post-quantum e2e messaging, client-encrypted vault, email-like multi-operator
network, and first-class **share a secret like a message**. KeyPears is first
because the stack is one protocol story, not a password manager bolted onto a
chat SaaS after the fact.

## Status: what is real now

Honest list.

**Built and proven in the Astrohacker KeyPears path**

- Account identity with address-shaped names and proof-of-work gates where spam
  would otherwise be free.
- Client-side vault unlock and encryption; ciphertext-only sensitive fields on
  the node.
- Hybrid post-quantum message encryption and signatures on the messaging path.
- Same-domain send/receive and federated delivery between nodes.
- Share a vault secret as an encrypted message; recipient optional save-to-vault.

**In progress**

- Folding KeyPears fully into the Astrohacker product home.
- Production packaging, discovery, and the open path for other people to run
  nodes with their own domains.
- Polish that turns lab-proven paths into something you install without a map.

**Not this post**

- A claim that a new public host is live today.
- A rebrand name announcement (old posts still say “Astrohacker Keys (TBD)” for
  a reason).
- SMTP replacement, mailing lists, or “we fixed compromised devices.”

If a device is owned or a password is weak, cryptography will not save you. If
you need MIME and mailing lists, use email. KeyPears is for secrets and private
messages under modern crypto—not for recreating 1995’s mail stack.

## Why under Astrohacker

One of the through-lines of this company is that **cryptography is plumbing,
not a product category**. Money systems and secret systems both need boring,
defensible crypto so the interesting product can be something else: cash that
moves, secrets you can actually share safely, agents and humans with identity
under human control.

KeyPears is the identity, messaging, and secret-exchange layer of that picture.
It already showed up as the protocol direction for how services talk when we
wrote about EarthBucks network plans. Bringing it home to Astrohacker is the
same unification story as the rest of the portfolio: one company brand, one
front door, protocol-shaped infrastructure that other operators can run.

## What to do

Follow the company blog and [astrohacker.com](https://astrohacker.com). That is
the home for status as KeyPears moves in.

If you care about the crypto baseline, re-read the hybrid post-quantum post.
If you care about the company fold-in, re-read the portfolio unification post.
If you care about the product: password manager and private messaging, with
**developer secret share** as the wedge that neither email nor a siloed vault
solves alone.

We are not inventing a new category label for a pitch. We are finishing a system
that already had a launch and a protocol spine—and putting it where the rest of
Astrohacker lives.

Hack the universe.
]]></content:encoded>
            <author>Ryan X. Charles</author>
        </item>
        <item>
            <title><![CDATA[Astrohacker TermSurf 0.1.103: Our Own Nexus BBS and a Real Chat Client in a Pane]]></title>
            <link>https://astrohacker.com/blog/2026-08-02-nexus-host-and-ahnexus-chat</link>
            <guid isPermaLink="false">https://astrohacker.com/blog/2026-08-02-nexus-host-and-ahnexus-chat</guid>
            <pubDate>Sun, 02 Aug 2026 20:30:00 GMT</pubDate>
            <description><![CDATA[Since the port shortcut: we host Nexus at nexus.astrohacker.com, ship ahnexus for multi-channel chat and files in TermSurf, and keep finishing the browser file path—honest about what is still not full protocol parity.]]></description>
            <content:encoded><![CDATA[
You start a local server. You open it with **`ahweb 3456`**. The page is next
to the shell that launched it. Then you want the other half of a workday:
**talk to people**—channels, private messages, a console that is not IRC
cosplay in a separate app.

That used to mean leaving TermSurf. Now it can mean **`ahnexus`**: a full-pane
Nexus client in the same window, optionally pointed at **our** BBS.

On [July 29 we shipped bare-port localhost open](/blog/2026-07-29-port-shortcut-and-what-termsurf-is)
as **v0.1.90**. This post is the **user-facing arc after that**—not another
browser-feel field note. The biggest thing is **Nexus**.

## The short version

- **Hosted BBS** — **[nexus.astrohacker.com](https://nexus.astrohacker.com)** runs
  our production **Nexus** server (Fargate, durable data, TLS). Operator-grade
  first; not a claim of a giant public community overnight.
- **`ahnexus`** — PATH command in the Astrohacker package: multi-channel chat,
  Console (`>_`), topics, `/me`, channel list, PMs, broadcasts, Login avatar
  (CLI + form), Settings password change, files browse/transfer.
- **Files in the browser pane** — the path that started with “system file open
  works” is much closer to finished: drag upload, downloads, progress—so panes
  behave like a real desktop browser for upload/save, and Nexus files can move
  the same way.
- **Honest residual** — we closed **chat parity as good enough**, not “every
  Nexus frame.” Secrets, some slash polish, and deeper protocol areas continue
  under a planning epic. Full official desktop client parity is a horizon.

If you only remember one sentence: **TermSurf already put the web next to the
shell; now it can put a real multi-channel BBS client there too—and we run a
host you can log into.**

## What is Nexus?

**Nexus** is a modern multi-channel BBS: chat, user messages, broadcasts, files,
permissions, TLS—the stack documented for clients that speak its protocol.
Upstream lives at **[github.com/zquestz/nexus](https://github.com/zquestz/nexus)**
(server, client, trackers, docs). We are a **client** of that protocol, not a
fork that reinvented the wire.

The project’s author writes more widely at
**[thoughts.greyh.at](https://thoughts.greyh.at/)**—engineering notes, OSS, the
kind of terminal-adjacent work that sits next to why a BBS-in-a-pane is
interesting at all. Credit where it belongs; Astrohacker’s job is the
**TermSurf product surface** and **our** deployment of the server.

We use path-pinned **`nexus-common`** for framing and types. We do not invent
chat formats.

## Why host our own BBS

Third-party servers are fine for exploration. Product work needs a host we
control: deploy, passwords, operator accounts, smoke against a stable name.

So we stood up **`nexus.astrohacker.com`**—digest-pinned **`nexusd`**, durable
storage, public TLS edge. That work closed as **nexus host deploy**. Chat that
only worked against someone else’s lag box was never going to be a product
story.

## What `ahnexus` is

**`ahnexus`** is the Astrohacker **Nexus TermSurf app**: Rust local server +
React SPA, full pane, same install story as `ahcalc` / `ahhelp`.

You connect (host, account, optional avatar). You get:

- **Channels** — join, leave, send, members, topics (`/topic`)
- **Actions** — `/me` as real `ChatAction::Me`, not cosmetic italics on normal
  text
- **Discovery** — `/channels` lists the server catalog on **Console** (not only
  rooms you already joined)
- **PMs** — `/msg nick text`, tabs at `/chat/pm/…` (no messaging yourself; the
  protocol forbids it)
- **Broadcasts** — `/broadcast` when permitted; inbound `ServerBroadcast` as
  Console lines
- **Console (`>_`)** — system lines, lists, broadcasts—not a place for plain
  room chat
- **Avatar** — `--avatar /path/to.png` or pick/drop on Connect; sent on
  **Login** each session (BBS sessions do not magically keep last week’s face
  after a full disconnect)
- **Files** — browse the user area; download/upload through the product path

It is a **usable multi-channel client**, not a pixel clone of the official
Nexus GUI, and not every protocol module (voice, news, full admin).

### How you try it

Apple silicon, Astrohacker cask installed:

```sh
ahnexus
```

Connect to **`nexus.astrohacker.com`** (or any Nexus host you use). Prefer the
docs and in-app help (`ahhelp`) for flags and smoke paths—including
`--avatar` for scripted login.

Public TermSurf source stays on the usual track:
**[github.com/astrohackerlabs/termsurf](https://github.com/astrohackerlabs/termsurf)**.
Install remains Homebrew cask **`astrohacker`** when you want the packaged app.

## Files: finishing the pane browser story

The [July 28 field note](/blog/2026-07-28-since-help-quit-file-open-and-password-plans)
was honest: **system file open** worked; the rest of transfer was still coming.

Since then, the transfer path moved a long way: drag-and-drop upload, multi-file
cases, downloads to disk, progress feedback. That matters for ordinary websites
**and** for Nexus file areas. A chat client that can list files but cannot save
them is a museum exhibit.

Password-manager and cloud vault work continue under their own epics. This post
does **not** claim a vault launch.

## What we are not claiming

- **Not** “full Nexus protocol done.” We closed **ahnexus chat parity** as
  good enough for multi-channel use: topics, list, `/me`, PMs, broadcasts,
  avatar. **Deferred** on purpose: secret channels, join/leave system lines in
  the transcript, full slash-table polish, every Console notice type.
- **Not** English shell / model marketplace / wallet as available SKUs.
- **Not** “we are a model lab.”
- **Not** a soft-open of every Astrohacker cloud product.

Further protocol work (secrets, voice, news, admin, deeper users/files, client
hygiene) is planned under epic **Nexus protocol client parity**—issues and
experiments, not a single big-bang rewrite.

## The line

Monorepo product crates moved through the **late 0.1.9x** range into
**0.1.103** in this window. Public cask version is whatever your tap last
installed; upgrade when you want host, `ahnexus`, and file pins together.

## Install

Apple silicon, Homebrew:

```sh
brew tap astrohackerlabs/astrohacker
brew trust astrohackerlabs/astrohacker
brew install --cask astrohacker
```

App: **`/Applications/Astrohacker TermSurf.app`**. PATH tools include
`ahterm`, `ahweb`, `ahsh`, `ahcalc`, `ahhelp`, **`ahnexus`**, and the Chromium
helper as packaged.

## Close

Localhost by port number was a small gift to a port-heavy day. **Nexus in a
pane** is a larger one: the same layout that holds your agent and your frontend
can hold multi-channel chat against a host we operate—or any Nexus BBS you
choose.

Upstream protocol and server: [github.com/zquestz/nexus](https://github.com/zquestz/nexus).  
Author’s writing: [thoughts.greyh.at](https://thoughts.greyh.at/).  
Our public TermSurf source: [github.com/astrohackerlabs/termsurf](https://github.com/astrohackerlabs/termsurf).

Open TermSurf. Run **`ahnexus`**. Connect. Stay in the window.
]]></content:encoded>
            <author>Ryan X. Charles</author>
        </item>
        <item>
            <title><![CDATA[Astrohacker TermSurf v0.1.90: Open Localhost by Port Number]]></title>
            <link>https://astrohacker.com/blog/2026-07-29-port-shortcut-and-what-termsurf-is</link>
            <guid isPermaLink="false">https://astrohacker.com/blog/2026-07-29-port-shortcut-and-what-termsurf-is</guid>
            <pubDate>Wed, 29 Jul 2026 12:54:59 GMT</pubDate>
            <description><![CDATA[ahweb opens local servers from a bare port number. Astrohacker TermSurf: terminal, real browser panes, and shell in one window for agentic engineers.]]></description>
            <content:encoded><![CDATA[
Your frontend is on **3456**. Your API is on **8787**. The throwaway fixture
server from five minutes ago is on whatever free port the tool printed and you
already forgot the host half of the string.

You do not want to type `localhost` again. You want the **number**.

In **Astrohacker TermSurf**, **ahweb** now treats a bare port as a local
server: `ahweb 3456` opens **`http://localhost:3456`**. Same idea if you are
already in the browser pane—put **`3456`** in the URL bar and go.

## The tax you stop paying

Local development is a parade of short-lived HTTP servers. Frameworks,
dashboards, OAuth callbacks, docs previews, calculators, mock APIs—almost all
of them are “something on this machine, this port.”

The full URL is honest. It is also **noise**. You already know the host is
localhost. The only thing that changes all day is the **port**. Re-typing
`http://localhost:`—or even `localhost:`—is pure tax between “server is up” and
“I can see it.”

Chrome and Safari do not care how you feel about that tax. They live in another
space. TermSurf lives **next to the shell** that started the server. The
browser should meet you at the same level of shorthand you already use when you
read a log line that says `listening on 5173`.

## What you do now

**From the shell:**

```sh
ahweb 3456
```

**From the URL bar** (Control mode, edit the location, submit):

```text
3456
```

Both mean: open **HTTP on this Mac, that port**. No host. No scheme typing
ceremony for the common case.

You still use full URLs when you need them—`https://example.com`,
`localhost:3456` with the host spelled out, real paths. The port shortcut does
not replace the web. It removes friction from the case you hit most while
building.

## Why this is more useful than it looks

A small shortcut is only small if you use it once. Agentic and terminal-first
days are **port days**:

- You spin a UI, open it, kill it, spin another.
- An agent prints a local URL; you only need the number.
- You keep two services up and jump between ports without leaving the terminal
  window.
- You demo a pane layout: shell in one, local app in another—handoff is a
  four-digit gesture, not a mini-essay in the address bar.

TermSurf’s job is to keep **computer and web** in one place. If opening the
local web still feels like “go use a different app and type a hostname,” the
product is fighting itself. Bare ports are the product agreeing with how local
servers actually work.

## The day

Start the frontend. Type the port. Pane loads. Hit the backend health route on
another port. Flip back. Stay in **ahterm**. Keep the coding agent where it is.
Do not Cmd-Tab to a browser profile that still has your bank tab from last
night.

That loop shows up every time something listens. The shortcut only pays off
because the browser already lives next to the shell—which is the product.

## Astrohacker TermSurf

**The Agentic Hacker’s Terminal.** The installable product is **Astrohacker
TermSurf**.

It is a **terminal emulator** with a **webview overlay protocol**: real browser
engines can run **inside terminal panes**, not only as a separate OS browser.
You browse the web, hack the web, and show real GUIs next to the shell—same
window, same session, same muscle memory for splits and focus.

Designed for **agentic engineers** who want maximum power over **their own
computer and the web**—not a toy embedded WebView, and not four consumer SKUs
pretending to be one product.

### Three layers you actually use

- **Terminal** — Ghostty-class host (`ahterm`). Panes, tabs, serious terminal
  behavior.
- **Browser** — Chromium-backed panes (`ahweb`). Real engine, real pages, in
  the layout you already split for code and agents.
- **Shell** — Nu-powered product shell (`ahsh`), with traditional shell escape
  hatches as the product documents them.

Under the hood that maps to engines and tools people already trust (Ghostty,
Chromium, Nushell). You install **one** desktop package—Homebrew cask
**`astrohacker`**—not a shopping cart of peer apps. The CLIs are components of
TermSurf, not separate marketed products.

### What ships vs what does not

**Ships today (Apple silicon macOS):** the desktop terminal, browser panes,
shell, and the helpers that make panes work. Traditional terminal workflows
work **without** an Astrohacker account.

**Not available as “use it now” product** (direction only until we say
otherwise): English default AI shell, model marketplace, hosted models as a
public SKU, free-credit soft launch, wallet / Economy commerce surfaces. We
build toward an agent-native future; we do not fake the inventory.

The **cloud** side of the company is **in progress**. You do not need a web
account to install TermSurf and work offline. When cloud is ready for ordinary
use, we will say so in plain English—not as a scavenger hunt.

## Install

Apple silicon, Homebrew:

```sh
brew tap astrohackerlabs/astrohacker
brew trust astrohackerlabs/astrohacker
brew update
brew upgrade --cask astrohacker
```

App: **Astrohacker TermSurf** in Applications. On `PATH`: **`ahterm`**,
**`ahweb`**, **`ahsh`**, and friends. Need a cheatsheet after install? Type
**`ahhelp`** inside TermSurf.

Type the port. Keep the rest of the day in the same window.
]]></content:encoded>
            <author>Ryan X. Charles</author>
        </item>
        <item>
            <title><![CDATA[Astrohacker TermSurf v0.1.88: Since Help and Quit: File Open That Works, Transfers Still Coming, and a Real Password Vault Plan]]></title>
            <link>https://astrohacker.com/blog/2026-07-28-since-help-quit-file-open-and-password-plans</link>
            <guid isPermaLink="false">https://astrohacker.com/blog/2026-07-28-since-help-quit-file-open-and-password-plans</guid>
            <pubDate>Tue, 28 Jul 2026 12:23:37 GMT</pubDate>
            <description><![CDATA[After ahhelp and chrome quit: host-mediated file open and folder upload in TermSurf Chromium (~0.1.88), downloads and drag still in progress, password-manager epic with KDBX interop—cloud still building, not launched.]]></description>
            <content:encoded><![CDATA[
You open **ahweb**, land on a page with a normal `<input type="file">`, and
click it. A real **macOS open panel** appears—owned by the app you launched,
not a stuck helper sheet in the Dock. You pick a file. The page gets it. You
try **upload folder** on a site that wants a tree; relative paths come through
the way desktop Chromium would send them.

That is not a marketing demo. It is the browser surface inside **Astrohacker
TermSurf**, finally doing the first half of “use the web like a desktop browser
in a pane.”

On [July 27 we wrote about ahhelp, top-right quit, and shell
discovery](/blog/2026-07-27-since-engine-pins-help-quit-and-shell-discovery)—product
line roughly **0.1.84–0.1.87**. This post is what landed **after** that window:
file **open** that works, an honest list of file transfer still missing, and a
locked plan for a password manager that can talk **KeePass KDBX**—without
pretending the cloud product is open for business.

## The short version

- **Done — system file open.** Host-mediated **NSOpenPanel** for single file,
  multi-select, and **directory upload** (`webkitRelativePath`). Shipped on the
  product fork pins; monorepo crates **0.1.88**.
- **In progress — the rest of file transfer.** Finder **drag upload**, **save**
  / download UX, and **drag download** to disk. Tracked separately; not claimed
  here.
- **Planned — password manager.** Vault stays Astrohacker’s model. **KDBX 4.x**
  import/export is interop for common logins, not “we became KeePass.” Fill and
  save in Chromium, CLI, and TermSurf apps under **explicit consent**.
- **Cloud — still building.** Account and vault groundwork continue under the
  hood. This is **not** a launch, soft-open, or “go create an account” post.
- **Line — ~0.1.88.** Upgrade the cask when your tap has the chooser pins.

If you only remember one sentence: **you can pick files and folders for upload
in TermSurf Chromium now; downloads and drag are next; passwords are a real
product plan, not a finished vault product.**

## File open that behaves like a browser

Embedded Chromium in a terminal host does not magically own AppKit sheets.
When the engine asked for a file dialog from the wrong process, you got the
worst of both worlds: no usable panel, or a helper that looked like it owned
the machine.

The path that works:

1. The **engine** parks the chooser request.
2. **ahterm** (the real host app) runs **NSOpenPanel**.
3. Chosen paths (or cancel) come back over the **TermSurf** protocol.
4. The page sees ordinary file-input results.

That is the same “host mediates, engine does not pretend to be the macOS app”
idea as the rest of TermSurf—not a second file stack invented for marketing.

### Folders, not only single files

Directory upload is not “attach one path and hope.” The host walks the tree
**off the UI thread**, builds the multi-file list with relative paths, and
finishes on the UI path the engine expects. We hit a hard fail when the walk
ran on the UI thread (blocking asserts / abort). The fix is boring and correct:
enumerate where blocking is allowed, then complete.

What you can try after upgrade: any site with a file input, multi-select, or
“upload folder.” If the open panel never appears, or a folder selection freezes
the pane, say so—those are regressions against this stretch, not known “maybe
later” gaps.

## What is not done yet

Closing file **open** did not close file **transfer**. Still open work:

- **Drag upload** — Finder → page drop target / file input in the pane.
- **Downloads** — silent Downloads-folder placement *and* system **Save** when
  the product path needs a save panel, with ordinary completion feedback.
- **Drag download** — page / browser surface → Finder (or the closest macOS
  behavior we can ship honestly).

Until those land, vault **import** is “pick a file” capable; **export/save** and
“drop the `.kdbx` on the page” are not the full desktop story. We will not
paper over that with half-claims.

## Why this matters for passwords

We opened a **Password Manager** epic with a locked product intent.

The **vault** stays Astrohacker’s design: versioned per-secret ciphertext,
multi-tenant cloud, unlock under the user’s keys. It is **not** “the product
is a KeePass database.” **KeePassXC-class KDBX 4.x** is the **migration and
interop** format—import and export common login fields (title, username,
password, URL, notes), refuse attachments instead of silently dropping them on
the crypto path, accept documented lossy group flatten when needed.

Where people type passwords:

- **TermSurf Chromium** — fill from vault and save into vault via the
  password-manager surface (engine hooks TBD by follow-on issues).
- **CLI** — get/save after appropriate account / unlock.
- **TermSurf apps** — may request a credential under **explicit user
  consent**, not ambient full vault dump to every pane.

Passkeys and other non-file secrets may come later. KDBX is the on-ramp and
off-ramp, not the ceiling.

[Earlier cloud field notes](/blog/2026-07-26-since-hard-refresh-engines-shell-and-cloud)
already named vault **groundwork** and a real **KDBX 4.x** package path. This
post is the product plan that sits on top of that foundation—and the reason
file open had to land first. Without a working chooser, “import a password
file” is fiction.

None of that means “password manager available now.” It means the next
surfaces have a map: transfer the rest of the files, then wire fill/save and
import/export where people actually live.

## Cloud: still in the shop

TermSurf remains the interface you run **locally**. The company still builds a
**cloud backend for the terminal**—accounts, keys, vault, later sync and more.
That work is **in progress**.

This post does **not** open a public onboarding tour, does **not** treat guest
or signed-in cloud homes as ready, and does **not** ask you to live in a web
account to use the terminal you already installed. When the cloud side is ready
for ordinary use, we will say so in plain English.

## Upgrade

Apple silicon, Homebrew:

```sh
brew tap astrohackerlabs/astrohacker
brew trust astrohackerlabs/astrohacker
brew update
brew upgrade --cask astrohacker
```

Install layout is unchanged: **Astrohacker TermSurf** in Applications;
**`ahterm`**, **`ahweb`**, **`ahsh`**, **`ahcalc`**, **`ahhelp`** (and engine
helpers) on `PATH`. File open needs a cask build that includes the **pinned**
chooser tips—roughly the **0.1.88** monorepo line and whatever revision your
tap publishes next. Full contract:
[homebrew docs](https://astrohacker.com/docs) when you need paths and package
names.

## Not this post

- Not a re-tour of [ahhelp, quit, and banner discovery](/blog/2026-07-27-since-engine-pins-help-quit-and-shell-discovery)—those already shipped in the previous field notes.
- Not the [economic singularity vision essay](/blog/2026-07-27-our-vision-for-the-economic-singularity)—direction, not a ship list.
- Not “downloads and drag work today.”
- Not “password manager / KeePass sync available now.”
- Not a soft-launch map of cloud accounts or OAuth-from-the-CLI as public product.
- Not “AI marketplace available now.”

## One more thing

Keep the cask current. The last stretch taught the product how to explain
itself and how to leave cleanly. This stretch teaches the embedded browser how
to **take files from the Mac** the way users already expect.

Downloads and drag close the loop. The password epic is where that loop pays
off for secrets—import, export, fill, save—without turning the vault into
someone else’s file format.

If open panels still fail after upgrade, or a folder upload aborts the engine,
report it. The point of shipping every few days is not the version number; it
is whether a pane still behaves like a tool you trust with a real workday.
]]></content:encoded>
            <author>Ryan X. Charles</author>
        </item>
        <item>
            <title><![CDATA[Since Engine Pins: Help in a Pane, Quit in Chrome, and a Shell That Points You]]></title>
            <link>https://astrohacker.com/blog/2026-07-27-since-engine-pins-help-quit-and-shell-discovery</link>
            <guid isPermaLink="false">https://astrohacker.com/blog/2026-07-27-since-engine-pins-help-quit-and-shell-discovery</guid>
            <pubDate>Mon, 27 Jul 2026 11:45:00 GMT</pubDate>
            <description><![CDATA[After the pin-and-cloud post: ahhelp (in-pane product docs), ahweb’s top-right quit, ahsh banner discovery, ahcalc SPA packaging fixed—product line ~0.1.84–0.1.87.]]></description>
            <content:encoded><![CDATA[
You open **Astrohacker TermSurf**, land in **ahsh**, and the banner does not only
mention Shift+Tab. It tells you to type **ahweb**, type **ahhelp**, and type
**ah** then Tab. You run **ahhelp**, and a full-pane cheatsheet opens with the
same GlyphRain dark as the calculator—host keybinds, browser modes, shell
dialects, and a short note on what the **TermSurf protocol** actually is. You
flip to **ahweb**, finish a page, and hit a real **×** in the top-right of the
chrome instead of hunting **:q**.

None of that is a new architecture. It is the product explaining itself and
closing cleanly after a week of fresher engines and cloud groundwork.

On [July 26 we wrote about engine pins, shell tips, and the cloud behind
TermSurf](/blog/2026-07-26-since-hard-refresh-engines-shell-and-cloud)—Chromium
**150**, Ghostty on Zig **0.16**, quieter ahweb chrome, Nu/Reedline on main,
roughly **0.1.79–0.1.83**, plus honest cloud progress. This post is what landed
**after** that window for day-to-day use.

## The short version

- **ahhelp** — new TermSurf app: in-pane product help at **`/ahterm`**,
  **`/ahweb`**, **`/ahsh`** (tabs are real routes). Host defaults and keybinds,
  ahweb modes, ahsh Nu↔zsh, copy-paste config, Caps Lock tip, and a plain
  sentence about **webview overlays** (why TermSurf is not stock Ghostty).
- **ahsh banner** — discovery lines for **ahweb**, **ahhelp**, and **ah** + Tab;
  command tokens painted **cyan** like Nu’s default external-command style.
- **ahweb** — **top-right quit (×)** on the nav chrome (width matched to the
  rest of the strip). **:q** / Ctrl+C still work.
- **ahcalc** — release packaging actually ships the SPA **`build/client`** so
  the cask calc is not empty chrome.
- **Readability** — shared muted text token lifted so secondary copy is not
  comment-gray across help, calc, and the webapp.
- **Line** — monorepo product crates roughly **0.1.84–0.1.87**. Upgrade the cask
  when your tap has the bits you care about.

If you only remember one sentence: **the stack got fresher last post; this
stretch makes TermSurf self-explaining and easier to leave without memorizing
commands.**

## ahhelp — docs that live in a pane

**ahhelp** is a first-class TermSurf CLI, same family as **ahcalc**: one binary,
full-pane web UI, close with × or Esc. It is not a link out to the marketing
site. It is product memory for people who already installed the terminal.

The cheatsheet is three routes, not a single scroll dump:

- **`/ahterm`** (default) — what TermSurf is, host keybinds, stock defaults,
  config path, pasteable product defaults, Caps Lock → Control, Ghostty docs
  via `ahweb ghostty.org`.
- **`/ahweb`** — modes (Browse / Control / Edit / Command), navigation keys,
  quit paths.
- **`/ahsh`** — Nu vs zsh, **Shift+Tab**, `SHANNON_MODE`, sample syntax, and
  `ahweb` pointers to upstream Nu and zsh docs.

The **What is ahterm?** lead now says the quiet part out loud: TermSurf is
Ghostty-based **plus** the **TermSurf protocol**—CLI apps can load real browser
engines as **webview overlays inside terminal panes**. That overlay model is
why the product exists and what stock Ghostty does not do. Host splits, shell,
and pane apps sit under that fact instead of pretending we only re-skinned a
terminal.

Visual chrome matches the rest of the suite: brand header, glass cards, Glyph
Rain. Muted body text uses the shared brighter secondary token so the long
copy is readable.

## Shell intro that names the suite

**ahsh** already said **Shift+Tab** toggles Nu and zsh. New users still need a
map of the CLIs on `PATH`.

Full and short banners now include, after the mode line:

- Type **ahweb** to browse the web.
- Type **ahhelp** for quick help.
- Type **ah** then **Tab** to see more commands.

The command tokens use the same cyan as Nu’s default **`shape_external`** so
they look like first-token externals on a normal prompt—not green “success”
noise.

## ahweb — quit without the command bar

Browse and Control still own most of the story. The missing piece for muscle
memory from every other app was a **visible quit** control.

ahweb now has a **×** on the top-right of the chrome, sized like the rest of
the nav strip. Prefer **:q** or Ctrl+C if you live in the command bar; the
button is for everyone else (and for the days you forget the colon).

## ahcalc packaging (one honest fix)

ahcalc was already the scientific calculator pane. A release-stage gap meant
some packaged builds could miss the SPA client tree. The stage now ships
**`build/client`** with the binary so **Homebrew calc** matches what developers
run from a full tree. If calc looked broken after install, upgrade and try
again—not a new product, a payload that finally matches the app.

## Upgrade

Apple silicon, Homebrew:

```sh
brew tap astrohackerlabs/astrohacker
brew trust astrohackerlabs/astrohacker
brew update
brew upgrade --cask astrohacker
```

Install layout stays the same: **Astrohacker TermSurf** in Applications;
**`ahterm`**, **`ahweb`**, **`ahsh`**, **`ahcalc`**, **`ahhelp`** (and engine
helpers) on `PATH`. Full contract: [homebrew docs](https://astrohacker.com/docs)
when you need paths and package names.

## Not this post

- Not the [economic singularity vision essay](/blog/2026-07-27-our-vision-for-the-economic-singularity)—that is direction, not a ship list.
- Not a soft-launch map of cloud accounts, OAuth-from-the-CLI, or bookmarks
  sync.
- Not a tmux multi-webview architecture diary (we assessed it; it is not a
  user feature today).
- Not “AI marketplace available now.”

## One more thing

Keep the cask current. The last post refreshed engines and shell pins under
your feet. This stretch puts **help, discovery, and quit** where your hands
already are—pane, banner, chrome.

If **ahhelp** is missing a binding you use every day, or the banner still
sends you nowhere useful, say so. The point of shipping every few days is not
the version number; it is whether a new pane still feels like a tool you can
learn without leaving the terminal.
]]></content:encoded>
            <author>Ryan X. Charles</author>
        </item>
        <item>
            <title><![CDATA[Our Vision for the Economic Singularity]]></title>
            <link>https://astrohacker.com/blog/2026-07-27-our-vision-for-the-economic-singularity</link>
            <guid isPermaLink="false">https://astrohacker.com/blog/2026-07-27-our-vision-for-the-economic-singularity</guid>
            <pubDate>Mon, 27 Jul 2026 10:15:52 GMT</pubDate>
            <description><![CDATA[Human trade built today’s economy. Agents with tools and budgets will build the next. How Astrohacker aims to create the rails—and let users own a piece.]]></description>
            <content:encoded><![CDATA[
Most of the economy still looks like **person ↔ person**. You buy from a shopkeeper, hire a contractor, pay a freelancers. On the web and the phone, the counterparty is often a **corporation’s computer**—you still decide and pay, but the other side is software running for a company.

We are only in the early innings of putting **AI agents** inside businesses. They draft, search, call APIs, open tickets. That is real, and it is still mostly *tools in human hands*.

What comes next is not “smarter autocomplete.” It is agents that do not only *use* tools, but **spend**—endowed with a **budget**, sent into the world to accomplish a goal, and allowed to pay for what the goal requires. That is the last mile of agent tooling. Once trade among agents is normal, markets do not grow linearly. They explode.

We call the threshold where that happens the **economic singularity**: the moment when the **AI ↔ AI** (and agent-mediated) economy **outgrows** the human ↔ human economy—and even the familiar human ↔ corporation economy. Not as a doomsday slogan. As a claim about **scale of trade and wealth creation**.

Astrohacker’s vision is simple to say and hard to build:

**Empower our users to create and own a piece of the economic singularity.**

## The economy as it is

For most of history, commerce assumed humans at both ends of the deal—or a human on one end and an institution on the other. Corporations automated the *storefront* and the *ledger*. They did not put an autonomous economic actor on your side of the table with a purse and a mandate.

Agents today are closer to interns with a browser: powerful, cheap, unreliable without supervision, and almost never allowed to open the company card without a human in the loop. That is the right default *for now*. It is not the end state.

## Agents with tools are not enough

Give an agent a shell, a browser, a calendar, a CRM. Useful. Still incomplete.

The missing tool is **money with a policy**. A budget is not a metaphor. It is a constrained account the agent can draw on to:

- buy API calls, compute, data, or services;
- pay other agents for work;
- settle obligations when a goal requires a real-world (or real-internet) transaction.

Without a budget, an agent is a brilliant tourist. With a budget, it is a participant. That is the **final stage of agent tooling**: not one more plugin, but **economic agency**.

## Why that becomes a singularity

Markets compound. When agents can hire other agents, specialize, and re-spend, the number of transactions is no longer capped by human attention or 9-to-5 staffing. Specialization deepens. Latency drops. Entire categories of trade that were not worth a human’s time become viable at machine scale.

We are not claiming that day is next Tuesday. We are claiming the direction is obvious once budgets are normal—and that **whoever owns productive capacity in that economy** owns a stake in historic wealth creation. Watching is not a strategy. **Creating** is.

## How you own a piece: you create it

You do not get a claim on the economic singularity by holding the right ETF ticker invented after the fact. You own a piece by **running economically productive agents**—a team that trades with other agents (and with people and services) to create value under your goals and constraints.

That is the product promise underneath the phrase:

- **You** set goals, risk, and budgets.
- **Your agents** execute, spend within policy, and trade.
- **The network** of other agents and markets is where value is discovered.

Astrohacker exists so that path is not reserved for a handful of labs or platforms. We want **users**—builders, operators, small teams—to be able to field that team and keep the upside.

## What we are building

Two layers, same idea as email:

| Layer | Email analogy | Agent economy |
| --- | --- | --- |
| **Protocols** | SMTP and friends—open rails anyone can implement | **KeyPears** and related protocols: identity, secrets, and trade primitives that extend the internet for agents |
| **Marketplace / product** | Gmail—the place people actually gather | The **Astrohacker webapp and marketplace**, plus **TermSurf** as the on-device surface where work already lives |

In short: **Astrohacker is to the agent economy what Gmail was to email**—not only a brand, but a **usable square on top of protocols** that define how the network talks.

Concretely, the arc looks like this:

1. **On-device power** — [Astrohacker TermSurf](/): real terminal, real browser engines in panes, local-first control. The place you live while agents and tools grow up around you.
2. **Cloud backbone** — the company webapp as account, identity, vault, and eventually the home for agents and marketplaces. Foundation work is in progress; it is not a soft-open “agent mall” yet.
3. **Agents with tools** — embed AI agents in the webapp with tools they can call. Direction, not a feature checklist of what you can click today.
4. **Budgets** — a first-class **cryptocurrency (and later broader) budget** an agent can spend to pursue a goal under your rules. That is the economic hinge.
5. **Marketplace + economy** — a place people and agents gather to trade, on rails that are not a single closed silo.

We are building **both** the marketplace **and** the economic stack—not a brochure site that points at someone else’s rails.

## Honesty about the timeline

This post is **vision**, not a ship announcement.

- **Shipped and shipping:** downloadable TermSurf, the browser-in-terminal product line, ongoing cloud app work (accounts, keys, vault groundwork, deploy path). See recent engineering posts on this blog for what actually landed.
- **Direction, not “available now”:** full agent teams with spendable budgets, a liquid AI↔AI marketplace, English shell as the default interface to that world, hosted model marketplace economics. We will not pretend those are installable features until they are.

The economic singularity is a **north star**. We build toward it in public, product by product.

## The nutshell

The economy today is still mostly humans and human institutions. Agents are arriving with tools. The next leap is agents with **budgets**. When AI↔AI trade outgrows human-scale commerce, that is the **economic singularity**.

**You own a piece by creating it**—fielding agents that work and trade under your control.

**Astrohacker** is building the **protocols** (KeyPears and friends) and the **marketplace** (webapp + terminal surface) so our users can do exactly that: **create and own a piece of the economic singularity.**

If you want the product that exists today, start with [TermSurf](/) and the [blog](/blog). If you want the long game, this is it.

Hack the universe.
]]></content:encoded>
            <author>Ryan X. Charles</author>
        </item>
        <item>
            <title><![CDATA[Since Hard Refresh: Engine Pins, Shell Tips, and the Cloud Behind TermSurf]]></title>
            <link>https://astrohacker.com/blog/2026-07-26-since-hard-refresh-engines-shell-and-cloud</link>
            <guid isPermaLink="false">https://astrohacker.com/blog/2026-07-26-since-hard-refresh-engines-shell-and-cloud</guid>
            <pubDate>Sun, 26 Jul 2026 20:06:30 GMT</pubDate>
            <description><![CDATA[After the Chromium-only feel fixes: fresher Chromium and Ghostty pins, cleaner ahweb chrome, Nu on main for ahsh, product line ~0.1.83—and real progress on the cloud backend for the terminal.]]></description>
            <content:encoded><![CDATA[
You upgrade **Astrohacker TermSurf**, open a pane, click into the URL field, and
the caret lands where you meant. The nav chrome does not flash a second color
under the pointer. The shell under it is still **ahsh**, still Nu-powered, on a
newer upstream tip. None of that is a reorg. It is the same product, a few days
of pin and host work after the last feel-good Chromium week.

On [July 22 we wrote about hard refresh, flick scroll, and video](/blog/2026-07-22-hard-refresh-flick-scroll-and-video)—the
day-to-day wins after [Chromium only—for now](/blog/2026-07-21-chromium-only-for-now).
That post closed around product line **~0.1.69–0.1.78**. This one is what landed
**after** that window: fresher engines and shell pins you can install, quieter
browser chrome, and honest progress on the **cloud app** that will back the
terminal—not a launch, not a soft-open tour.

## The short version

**Downloadable TermSurf family**

- **Chromium** product pin moved to Electron-stable chrome **150.0.7871.129**.
- **Ghostty** host advanced to current **main**, on **Zig 0.16**, with TermSurf
  IPC/runtime hardening so the host still talks cleanly to the engine.
- **ahweb** — no hover paint on the nav strip; Control-mode **URL click inserts
  at the cursor** instead of only “jumping” the field.
- **ahsh** — **Nushell** and **Reedline** re-pinned to upstream **main** (path
  coupled); product shell patches rebased (PATH union / lazy env surface kept).
- **Line** — monorepo product crates moved through roughly **0.1.79–0.1.83**.
  Upgrade the cask when your tap has the bits you care about.

**Cloud webapp (in development)**

- Same company arc: **on-device TermSurf**, **cloud backend for the terminal**.
- Already real in code and deploy path: account/settings, identity **keys**,
  **password vault** groundwork (including **KDBX 4.x**), shared UI, oRPC data
  plane, AWS deploy.
- **Not** pretend-shipped: bookmarks sync, polished password sync product,
  wallet, AI agent management and marketplace. Those are the destination.

If you only remember one sentence: **keep upgrading TermSurf from the tap; the
engines and shell got newer under your feet, and the cloud layer is being built
to meet the terminal—not replace it with a web demo.**

## What you can install today

### Fresher Chromium

The shipped engine pin is no longer stuck on an older patch of the same Electron
43 line. Product Chromium sits on **150.0.7871.129** (Electron stable chrome for
that cadence). Same family as the Chromium-only bet: one engine, security and
media path we actually ship—not tip-of-tree archaeology.

### Host and IPC (Ghostty / TermSurf)

The host terminal is not a frozen fork. Ghostty is on a current **main** tip
with the product patch series rebased, toolchain at **Zig 0.16**. Follow-up work
hardened TermSurf runtime details that only show up when the host and engine
handshake—socket env for children, interrupt-safe I/O, Darwin sockaddr details.
You should not need to care about those names; you should get a host that still
starts panes after the pin jump.

### ahweb chrome that stays out of the way

Two small Control-mode / browse-chrome changes:

- **No hover paint** on the nav strip—less visual noise when the pointer
  crosses buttons.
- **URL click → insert at cursor** when you are editing the bar, so a click
  behaves like an editor, not only like “select everything and hope.”

### Shell on newer Nu

**ahsh** still means Astrohacker Shell: Nu under the product CLI, Reedline as
the line editor, path-pinned forks. Both **Nushell** and **Reedline** moved to
upstream **main** tips in one pass so the path deps stay coherent. Product
behavior we care about (lazy traditional shell env, Nu-first PATH union so tools
like `cargo` do not vanish) was rebased with the tip—not thrown out for a clean
merge.

### Version line

After the last post’s **~0.1.69–0.1.78** window, the monorepo product crates
walked **0.1.79** through **0.1.83**. Exact cask revision is whatever you
installed last; the story is “several release bumps of host/engine/shell
pins,” not one magic number that fixes everything.

## Upgrade

Apple silicon, Homebrew:

```sh
brew tap astrohackerlabs/astrohacker
brew trust astrohackerlabs/astrohacker
brew update
brew upgrade --cask astrohacker
```

Install layout and names stay the same: **Astrohacker TermSurf** in
Applications, **`ahterm` / `ahweb` / `ahsh`** (and friends) on `PATH`. Details:
[docs/homebrew](https://astrohacker.com/docs) when you need the full contract.

## The cloud app—progress, not a product tour

TermSurf is the interface you run locally. The **webapp** is the cloud side of
the same product: account, sync, keys, vault, and later wallet and **AI agent
management / marketplace**. That is the plan. It is **not** “go open a secret
URL and pretend the backend launched.”

What has been built hard enough to name without lying:

- **Account and settings** — change password, delete account with real
  confirmation, session-aware shell chrome.
- **Identity keys** — KeyPears-shaped list/detail, rotation and re-encrypt
  flows, hybrid post-quantum framing where the product already claims it.
- **Password vault foundation** — lock/unlock, secret entries, authorization
  that does not trust the client on a good day; plus a real **KDBX 4.x**
  package path so import/export is not a toy JSON dump.
- **UI system** — shared kit and dialog shell so modals are one product, not
  five slightly different blurs.
- **Data plane and ops** — oRPC under `/api`, models that loaders can own,
  AWS deploy path, blog and app content that actually ships in the image.

What is **not** ready for “it works for everyone” language:

- Bookmarks and password **sync** as a finished product surface  
- Cryptocurrency **wallet** as a shipping feature  
- **AI agent management** and an **agent marketplace** as public UX  

Those are why the backend exists. They are not today’s install checklist.

When the cloud side is ready for you, we will say so in plain English—with a
normal entry path, not a scavenger hunt.

## Not this post

- Not a Chromium tip-of-tree diary.  
- Not a soft-launch map of guest vs signed-in homes.  
- Not “AI marketplace available now.”  
- Not a promise that every experimental route is public product.

## One more thing

Keep the cask current. The last post fixed **feel** on Chromium-only panes.
This stretch fixed **freshness** of the stack under those panes—and put real
mass behind the cloud backend that TermSurf will plug into.

If something still feels wrong after upgrade, say so. The point of shipping
every few days is not the version number; it is whether the terminal still
behaves like a tool you trust with an open day.
]]></content:encoded>
            <author>Ryan X. Charles</author>
        </item>
        <item>
            <title><![CDATA[Hard Refresh, Flick Scroll, and Video: What’s New After Chromium-Only]]></title>
            <link>https://astrohacker.com/blog/2026-07-22-hard-refresh-flick-scroll-and-video</link>
            <guid isPermaLink="false">https://astrohacker.com/blog/2026-07-22-hard-refresh-flick-scroll-and-video</guid>
            <pubDate>Wed, 22 Jul 2026 21:30:00 GMT</pubDate>
            <description><![CDATA[Since the Chromium-only cut: ignore-cache reload, trackpad inertia in panes, proprietary media for sites like X, faster lazy zsh, saner env merge, and TermSurf path cleanup.]]></description>
            <content:encoded><![CDATA[
You open a long page in an **Astrohacker TermSurf** Chromium pane, flick the
trackpad, and the document **keeps coasting** after your fingers leave the
glass. You hit **Cmd+Shift+R** (or type **`:rh`** in the command bar) and the
pane reloads **past the cache**. You open a video on X and it **actually
plays**.

That is the Chromium-only bet paying rent: one engine, finished enough to feel
ordinary.

On [July 21 we said Chromium only—for now](/blog/2026-07-21-chromium-only-for-now):
WebKit and Ladybird off the active product surface so one browser path can
mature. This post is what landed for **daily use** after that cut—not the
investor deck, not website tooling, not engine archaeology.

## The short version

- **Hard refresh** — ignore-cache reload: **Cmd+Shift+R** / **Shift+R**, and
  Control-mode **`:refresh hard`** / **`:rh`**. Soft stays **Cmd+R**, toolbar
  click, **`:refresh`** / **`:r`**.
- **Trackpad flick** — two-finger inertia (coast) works in Chromium browse
  panes.
- **Media** — proprietary codecs (Chrome branding path) so sites like **X** can
  play H.264 video in-pane.
- **Shell** — **lazy zsh** for a fast `ahsh` prompt; then a **Nu-first PATH**
  merge so zsh’s environment does not erase tools like `cargo`.
- **Housekeeping** — TermSurf **XDG / state paths** under the product name;
  pane content **corner clip** so overflow does not fleck the chrome.
- **Line** — monorepo product crates moved through roughly **0.1.69–0.1.78**;
  upgrade the cask when your tap has the bits you care about.

If you only remember one sentence: **Chromium-only bought us room to fix
reload, scroll feel, video, and shell startup—the stuff you touch every hour.**

## Hard refresh (cache-bust without leaving the pane)

Before this window, soft reload was easy and hard reload was not a trustworthy
product story. Soft still means normal reload. Hard means **ignore HTTP
cache**—the engine path is Chromium
`ReloadType::BYPASSING_CACHE`, not a soft `reload()` wearing a costume.

**Soft**

- **Cmd+R** (Command+R, no Shift)
- Toolbar refresh button
- Command bar: **`:refresh`** or **`:r`**

**Hard**

- **Cmd+Shift+R** / **Shift+R** (in Control / Browse when keys reach `ahweb`)
- Command bar: **`:refresh hard`** or **`:rh`**

**What we deliberately do not promise:** Shift+click on the toolbar as hard
refresh. Terminals (including our host) often treat Shift+mouse as selection /
“escape mouse grab” and **do not deliver Shift on the click** the way a
browser chrome does. Units that faked Shift on mouse-up were green; the
product was not. Hard reload lives on **keyboard and commands**, where
modifiers actually arrive.

## Trackpad flick / inertia

Direct scroll while fingers stay on the pad already moved the page. A
**flick**—lift and coast—did not. That is the difference between a remote
webview that only applies deltas and one that preserves a Mac **phase /
momentum** sequence after finger-up.

We filled more wheel fields first; that alone was not enough. Tracing showed
momentum can reach the engine; the remaining fix was routing synthetic wheels
through Chromium’s Mac **phase-handler** path (delayed physical `phase=ended`,
same family as Chrome’s `RouteOrProcessWheelEvent`) instead of a bare route
that could kill the fling at the phase boundary.

Operator check: long page, two-finger flick, **coast**. That closed the issue.

## Video in `ahweb` (X and friends)

Some sites never play without **proprietary codecs**. Our Chromium product
build was too thin for that world: no H.264 where the page expects it, so X
and similar media stayed silent or broken.

We enabled the product **proprietary codecs + Chrome ffmpeg branding** path
used for real playback. After the rebuild, **X video plays** in a TermSurf
Chromium pane. That is the user-facing bar—not a codec laundry list.

## Faster shell, correct environment

**Lazy zsh.** Spawning a full zsh for every alt-shell handshake blocked a
snappy `ahsh` start. Lazy startup lets the prompt arrive while zsh is not
holding the door. Shift+Tab to zsh still exists when you want it; the greeting
does not wait on a serial cold start.

**Env after lazy.** Speed without cargo is a trap. The follow-on fix keeps
**zsh as the base environment**, then merges with a **Nu-first PATH** (Nu
entries first, zsh entries deduped after) so tools you installed under zsh
still resolve and Nu’s own path additions are not clobbered.

Net: quick start, then an environment that still runs real work.

## Paths and pixels

**TermSurf XDG / state naming.** Config and state folders follow the product
name (**termsurf**), not a leftover “terminal” tree. If you had old paths, look
for the new tree after upgrade—same product, honest home on disk.

**Pane corner clip.** Web content no longer peeks past rounded pane corners as
a little fleck of overflow. Small visual, large “this is intentional chrome”
energy.

## Versions

Product crates in the monorepo stepped through roughly **0.1.69** to
**0.1.78** in this window. Public cask version may lag a commit or two—when
you upgrade, match the notes above to what your install actually contains
(`ahweb` hard refresh, coast, codecs, `ahsh` startup).

## What we did not cover here

- Investor deck / fundraising copy
- Website dev-server plumbing
- KeyPears or other non-TermSurf experiments

Those matter; they are not “open a pane and work.”

## Still Chromium only

The [previous post](/blog/2026-07-21-chromium-only-for-now) still holds:
**one** shipped browser engine. This work is what “focus” is for—reload that
matches developer muscle memory, scroll that matches a Mac trackpad, media
that matches the modern web, shell that starts fast without lying about PATH.

Install or upgrade when ready:

```sh
brew tap astrohackerlabs/astrohacker
brew trust astrohackerlabs/astrohacker
brew install --cask astrohacker
```

Then try three things: **flick** a long page, **hard refresh** with
**Cmd+Shift+R** or **`:rh`**, and open a **video on X**. If something still
feels wrong, that is useful signal—send it.
]]></content:encoded>
            <author>Ryan X. Charles</author>
        </item>
        <item>
            <title><![CDATA[Chromium Only (For Now): Why We Shelved WebKit and Ladybird]]></title>
            <link>https://astrohacker.com/blog/2026-07-21-chromium-only-for-now</link>
            <guid isPermaLink="false">https://astrohacker.com/blog/2026-07-21-chromium-only-for-now</guid>
            <pubDate>Tue, 21 Jul 2026 23:00:00 GMT</pubDate>
            <description><![CDATA[After 0.1.60 we fixed Chromium fullscreen, tried harder on WebKit and Ladybird, then archived them so one engine can finish—and come back later.]]></description>
            <content:encoded><![CDATA[
You open `https://astrohacker.com` in a pane, put **Astrohacker TermSurf** into
native fullscreen, and the glyph rain keeps moving. Links still navigate. The
page is not a frozen screenshot of yesterday’s Space.

That is the Chromium path working the way a hosted browser should.

What you will **not** find in a current install is a second or third shipped
engine helper. No `ah-webkitd`. No Ladybird. No “reserved Gecko” story on the
product surface. **One** browser engine ships: **Chromium**.

On [July 20 we field-noted 0.1.47 through 0.1.60](/blog/2026-07-20-astrohacker-0-1-60)—
TermSurf by name, Browse first, `ahcalc`, focus that stays local. This post is
what happened **after** that line: a hard day of engine work, then an honest
cut.

## The short version

- **Shipped browser:** **Chromium only** — panes, Homebrew package, warmups,
  docs, and marketing product copy.
- **Archived (not erased):** **WebKit** and **Ladybird** leave the active
  product. Patch history, closed issues, and old blog posts stay. They can
  return under **new** issues later.
- **Gecko residual scrubbed** — it was never a public ship engine; we stopped
  advertising it as reserved future furniture.
- **Chromium maturity first** — fullscreen / Mission Control freeze fixed for
  live webviews (helpers join the host Space; we did not ship a permanent
  “never background anything” hammer).
- **We tried before we cut** — WebKit got a live compositor path (rain that
  actually animates). Ladybird still painted black after real pin work. Cost
  stayed high; daily use stayed Chromium.
- **Also this window:** `ahcalc` no longer dies on Bun’s compiled `/$bunfs/…`
  argv; browser chrome labels follow a **naming convention** instead of a
  hard-coded engine table.
- **Line** — monorepo product crates through **0.1.68**; upgrade the cask when
  your tap has the Chromium-only package.

If you only remember one sentence: **we proved multi-engine can work; now we
ship one engine well so it can become boringly reliable—and invite the others
back when that job is done.**

## Why remove WebKit and Ladybird

Not because multi-engine was a fantasy. Astrohacker TermSurf already ran
**real** engines in terminal panes. Chromium, WebKit, and Ladybird were not
slideware. Gecko work produced scaffold and hard lessons
([why Gecko is the hard one](/blog/2026-07-12-why-gecko-is-the-hard-one)) without
a public ship contract.

The problem is **attention**.

Each engine is a fork, a helper, a presentation path, packaging, warmups,
docs, and a long tail of input and paint special cases. WebKit alone ate live
compositor work, hover paths, and build-shore qualification. Ladybird ate pin
isolation and still showed a **black pane** that navigated and titled correctly
while pixels refused to show. Chromium, the engine we actually live in for
product development and most web-developer testing, still had gaps—like
webview freeze after the host window changed Space or entered native
fullscreen.

Spreading effort across three (or four) engines leaves **none** of them at
“this is finished.” That is a bad trade for an early product.

So we made a deliberate cut:

- **Park** WebKit and Ladybird on the active product surface.
- **Focus** on Chromium until it is mature enough that “open a URL in a pane”
  stops being a research project.
- **Keep the door open** — multi-engine is architecture we already exercised.
  When Chromium is the solid default, other engines can earn a new issue and a
  new ship contract. History under `patches/` and the issue archive is how we
  reconstruct them—not a half-dead helper in every cask forever.

Not “we hate WebKit.” Not “Ladybird failed forever.” Not “multi-engine is
dead.”

**It is: one mature engine beats three half-done ones—for now.**

## What we did before we cut

Removal is easier to trust if you see the day we spent **trying**.

### Fullscreen that stays live (Chromium)

With the marketing site open, entering **native fullscreen** or moving the
host to another Mission Control desktop could freeze the page: rain stopped,
clicks died, the TUI stayed fine. Helpers had been left on the **previous**
Space while the host moved.

We fixed that on the Chromium path by **co-locating** helper source windows with
the host (or joining Spaces for non-visible helpers)—not by leaving a permanent
process-wide “disable occlusion backgrounding” flag in product spawn. Windowed
browsing, resize, focus, and cleanup stay ordinary. Fullscreen should feel
like the same browser, bigger.

That is the kind of defect we want headroom to chase next: presentation,
Spaces, polish, packaging—**one** stack at a time.

### WebKit: live rain, still expensive

WebKit’s old presentation path was snapshot-backed: capture bitmaps on discrete
events, ship those to the host. CSS animation and hover did not keep the pane
alive. We pushed a **live compositor** path so glyph rain could run for a full
minute without click-to-repaint theater, and we chased hover authority after
that.

Those issues closed as real progress. They also proved the bill: fork builds,
compositor seams, input special cases, two build shores, continuous tax. The
operator disposition was blunt: WebKit is not the day-to-day engine; Chromium
is. After Ladybird left, keeping WebKit as a second full ship contract was
still too much surface for MVP.

So WebKit left the **active** product the same way Ladybird did: out of
Homebrew and packaging, out of living docs and marketing claims, live fork no
longer required. **Historical** patch series and issues remain. Hover and other
WebKit product work are out of scope unless a future issue reopens the engine.

### Ladybird: black pane, then out

Ladybird still reported title, URL, and engine identity while painting a large
**black** rectangle—presentation, not “failed to spawn.” We offered render
services more uniformly, isolated pin hypotheses, and closed the paint issue
for **MVP without a full pixel fix**: multi-engine was already proven by
Chromium + WebKit; Ladybird was not required to ship.

Then we removed Ladybird from the active product surface entirely—release path,
pin, code, website—while keeping historical archives. A cask/tarball mismatch
on the way out taught the usual packaging lesson: formula body and archive
contents must stay in lockstep. The install story is Chromium-only now, on
purpose.

### Gecko residual

Gecko was never in the Homebrew ship set. After WebKit and Ladybird left,
living docs and crates still whispered “reserved” or kept scaffold around.
That confuses a Chromium-only product. We scrubbed the **active** residual and
left the historical narrative alone. No claim that Gecko “ships someday” until
someone opens a real issue and finishes the work.

## Small product fixes in the same window

Engine cuts were the headline. Two smaller changes still matter when you
upgrade:

- **`ahcalc`** — the compiled one-binary client was rejecting Bun’s synthetic
  `/$bunfs/root/ahcalc` argv entry as a user argument. Normal no-flag launch
  works again; real flags and `--server` still mean what they meant.
- **Browser labels** — pane chrome no longer depends on a hard-coded map of
  engine families. Helpers named like `{prefix}-{stem}d` display as `{stem}`
  (`ah-chromiumd` → `chromium`). Selection and routing are unchanged. When
  another engine returns, labeling does not require rewriting a private
  allowlist first.

## What still ships

Same install story, narrower engine list:

```sh
brew tap astrohackerlabs/astrohacker
brew trust astrohackerlabs/astrohacker
brew install --cask astrohacker
```

Or:

```sh
brew update
brew upgrade --cask astrohacker
```

App: **`/Applications/Astrohacker TermSurf.app`**. On PATH you still want
**`ahterm`**, **`ahsh`**, **`ahweb`**, **`ah-chromiumd`**, and **`ahcalc`**.
You should **not** expect WebKit or Ladybird helpers in a current package.

Still one cask. Still **Apple silicon**. Still **The Agentic Hacker’s
Terminal** as slogan—even when the app on disk is TermSurf and the browser
inside it is Chromium.

Worth five minutes after upgrade:

1. `ahweb https://astrohacker.com` — type into the page (Browse-first from
   0.1.60 still applies).
2. Enter native fullscreen — rain should keep moving; a link click should
   navigate.
3. Run **`ahcalc`** with no flags — it should start the client path, not die on
   a bunfs path argument.
4. Confirm you are not hunting for `ah-webkitd` or Ladybird in the cask.

Protocol and product docs: [How TermSurf Talks](/blog/2026-07-19-how-termsurf-talks),
[/docs](/docs), [Chromium docs](/docs/chromium). Prior field notes:
[0.1.60](/blog/2026-07-20-astrohacker-0-1-60).

## What this does not change

- **TermSurf** as the wire language and multi-pane host model.
- Historical posts and issues that named WebKit, Ladybird, or Gecko—those are
  the record, not active claims.
- Willingness to run **more than one** engine again when the primary path is
  mature enough that second engines are a choice, not a distraction.

Upgrade. Use Chromium panes hard. File Chromium bugs. When the default browser
path is boringly solid, other engines can come back the right way: a new issue,
a real ship contract, and a product that already works with one engine at
full strength.
]]></content:encoded>
            <author>Ryan X. Charles</author>
        </item>
        <item>
            <title><![CDATA[Astrohacker 0.1.60: TermSurf by Name, Browse by Default, Calc in a Pane]]></title>
            <link>https://astrohacker.com/blog/2026-07-20-astrohacker-0-1-60</link>
            <guid isPermaLink="false">https://astrohacker.com/blog/2026-07-20-astrohacker-0-1-60</guid>
            <pubDate>Mon, 20 Jul 2026 22:00:00 GMT</pubDate>
            <description><![CDATA[Field notes from 0.1.47 through 0.1.60: Astrohacker TermSurf.app, monogram dock and surfer titles, ahweb Browse-first, ahcalc, smarter split focus, and the live site.]]></description>
            <content:encoded><![CDATA[
You open the Dock and the app no longer says **Terminal**. The bundle is
**Astrohacker TermSurf**. The title bar falls back to a **surfer**, not a
ghost. You type `ahweb example.com`, hit Enter once, and keys go to the
**page**—not into a Control mode that asked for a second Enter before the
browser felt real.

That is the line from **0.1.47 through 0.1.60**.

On [July 18 we field-noted rounded panes and the welcome splash](/blog/2026-07-18-astrohacker-0-1-47).
On [July 19 we walked the TermSurf protocol](/blog/2026-07-19-how-termsurf-talks)—
host, client, engine helpers, protobuf on local sockets. This post is the
**user-facing delta** after those: what you install, what you click, what
focus does when you move between splits.

Still one cask. Still **Apple silicon**. Still **The Agentic Hacker’s
Terminal** as slogan—even when the app name on disk is TermSurf.

## The short version

- **Product name:** **Astrohacker TermSurf.app** in
  `/Applications` (cask token still `astrohacker`; CLI still `ahterm`).
- **Dock icon:** **Astrohacker monogram** (AH). The wave mark was tried for the
  host icon and then put back down—product _name_ stayed TermSurf.
- **Title defaults:** empty / fallback chrome uses **🏄** and **🏄 TermSurf**,
  not Ghostty’s ghost.
- **`ahweb` starts in Browse** — page first; Escape still reaches Control.
- **`ahcalc`** — scientific calculator as a **TermSurf app** (full-pane web
  UI), **one binary** for client and server roles, wired into the Homebrew
  package story.
- **Split focus stays local** — spatial up/down/left/right prefer the straight
  neighbor band; MRU no longer diagonal-jumps when a real orthogonal pane
  exists.
- **Public site** — live marketing surface kept in step (docs/product naming,
  welcome, polish). Stack work is ours; you care that [astrohacker.com](https://astrohacker.com)
  still looks like the product.
- **Line** — **0.1.50 … 0.1.60** on the usual tap.

If you only remember one sentence: **upgrade, open a URL without a second
Enter, split a 2×2 and move with the arrows, and run `ahcalc` if you want a
calculator that lives in a pane instead of another floating window.**

## The app is called Astrohacker TermSurf

For a long time the install said **Astrohacker Terminal** while the _protocol_
that makes browser panes work was already **TermSurf**. That split was
accurate for engineers and muddy for everyone else.

We renamed the **desktop product**:

- Bundle: **`Astrohacker TermSurf.app`**
- Install path: **`/Applications/Astrohacker TermSurf.app`**
- Docs and product copy that still meant “the host you launch” follow the new
  name

What we **kept** on purpose:

- Homebrew cask **`astrohacker`**
- PATH launcher **`ahterm`**
- Protocol name **TermSurf** (`termsurf.proto`, helpers, `TERMSURF_*` where they
  already lived)

**TermSurf** is still the wire language. **Astrohacker TermSurf** is the
window. If that sentence feels redundant, good—it is supposed to collapse the
old “Terminal vs protocol” gap, not invent a second SKU.

### Monogram on the Dock, surfer in the title

Icon work went in two honest steps.

1. First we put the **TermSurf product mark** (wave) on the host AppIcon so the
   rename had a face.
2. Then we **restored the Astrohacker monogram** as the Dock / Finder icon.
   The company mark owns the tile; the product name owns the string.

Title bar defaults were a separate leftover: empty surfaces and fallback titles
still smelled like **Ghostty** (ghost emoji, “Ghostty” wording). Defaults now
use the **surfer**—**🏄** alone, or **🏄 TermSurf** for the short branded
title. That is chrome text, not a second icon pipeline.

## Browse opens first

`ahweb` used to leave you in **Control** mode after launch. Opening a URL from
the shell meant: Enter to start the client, then **another** Enter (or mode
switch) before typing into the page felt normal. Fine for power users who live
in pane chords. Wrong for “I just opened google.com.”

**Browse is the default** on a normal launch. Keys go toward the page / overlay
path. The host still keeps a **Browse chrome allowlist** so the split and tab
bindings you need as a multi-pane product do not vanish the moment a document
has focus.

**Escape** still reaches Control. We did not delete the hatch. We stopped
making the hatch the front door.

## `ahcalc`: a calculator that is a TermSurf app

This line ships a real **TermSurf app** in the product story: **`ahcalc`**, a
scientific calculator with a full-pane web UI.

Shape that matters to you:

- **One on-disk binary** — client and server roles from the same file (no
  sibling `ahcalc-server` you have to keep next to it).
- **Local only** — the calculator UI is served on **loopback**; a second invoke
  finds the running server over a **Unix domain socket** and opens or reuses a
  pane.
- **No host port registry** inside `ahterm` — the app owns its process model;
  the host owns panes and the protocol.

This is not a second IDE. It is not “English shell.” It is a calculator that
uses the same browser-pane machinery as `ahweb`, so the product is allowed to
grow apps without inventing a different windowing system.

Homebrew packaging stages **`ahcalc`** with the cask contents (binary + static
payload). If your install is current, `ahcalc` should be on PATH with the rest
of the bundle. If something is missing after upgrade, the cask is the first
thing to reinstall—not a random npm global.

## Focus that does not teleport

We already fixed **split focus memory** so nested layouts remember where you
were when you re-enter a region. The next bug was subtler: **temporal MRU**
could yank you **diagonally** on a pure arrow move when a straight neighbor
existed.

Canonical 2×2:

```text
 TL | TR
----+----
 BL | BR
```

Focus **BR**, move **up**. You should land on **TR**—not **TL** because TL was
“recent.” Same idea for left/right along a row.

**Secondary-axis locality** means: after a pure orthogonal move, prefer panes
in the same **row** (for left/right) or **column** (for up/down) before MRU
gets a vote. Nested re-entry memory from the earlier fix still works. The
arrows should feel spatial again.

## The public front door

The install still points people at **astrohacker.com**. In this window we kept
the marketing surface aligned with the product rename (docs call the host
**Astrohacker TermSurf**, welcome splash still the default host front door,
footer and polish nits like putting **Austin** on the copyright line). Under
the hood the site package was rebuilt and redeployed on Cloudflare so the live
domain stays the one product story—not a second abandoned stack.

You do not need to care which web framework we use. You need the site and the
app to agree on the name.

## How to get it

Same install story, new app name in Applications:

```sh
brew tap astrohackerlabs/astrohacker
brew trust astrohackerlabs/astrohacker
brew install --cask astrohacker
```

Or upgrade if you already have the cask:

```sh
brew update
brew upgrade --cask astrohacker
```

App lands at **`/Applications/Astrohacker TermSurf.app`**. CLIs stay on PATH:
**`ahterm`**, **`ahsh`**, **`ahweb`**, engine helpers, and **`ahcalc`** when
the package includes it.

Worth five minutes after upgrade:

1. Confirm the Dock tile is the **monogram** and the app name is **TermSurf**.
2. `ahweb https://example.com` — type into the page without a second mode Enter.
3. Split a 2×2 and walk the arrows; focus should not diagonal-jump.
4. Run **`ahcalc`** once if you want the pane calculator.

Protocol detail is still in
[How TermSurf Talks](/blog/2026-07-19-how-termsurf-talks) and the
[TermSurf protocol docs](/docs/termsurf). Product docs start at
[/docs](/docs).

Upgrade. Open a URL. Move focus on purpose. The window should feel like one
product—with a name that matches the protocol that made it possible.
]]></content:encoded>
            <author>Ryan X. Charles</author>
        </item>
        <item>
            <title><![CDATA[How TermSurf Talks: The Protocol Behind Browser Panes in Astrohacker Terminal]]></title>
            <link>https://astrohacker.com/blog/2026-07-19-how-termsurf-talks</link>
            <guid isPermaLink="false">https://astrohacker.com/blog/2026-07-19-how-termsurf-talks</guid>
            <pubDate>Sun, 19 Jul 2026 18:00:00 GMT</pubDate>
            <description><![CDATA[What happens when you run ahweb: host, client, and engine helpers speaking one protobuf language over local sockets—so a real browser can live in a terminal pane.]]></description>
            <content:encoded><![CDATA[
You open a URL in a terminal pane and a **real** browser engine paints the page
beside your shell. No alt-tab. No second app fighting for focus. Chromium,
WebKit, or Ladybird—same product window.

That is not one magical binary doing everything. It is several processes that
have to agree on layout, tabs, input, and page state. The agreement has a name:
**TermSurf**.

**Astrohacker Terminal** is the product you install. **TermSurf** is the
protocol those pieces use to talk. This post is the builder’s tour: what
happens when you run `ahweb`, who is on the wire, and why the messages look the
way they do. For the full message catalog, see
[TermSurf protocol docs](/docs/termsurf). This is the story, not a field dump
of `termsurf.proto`.

## What happens when you run `ahweb`

Pick a boring URL and a shipped engine:

```bash
ahweb --browser chromium https://example.com
```

Roughly:

1. **`ahweb` is a client.** It does not embed Chromium. It finds the Terminal
   **host** and asks for browser work on a **pane** (the region you see).
2. **`ahterm` is the host.** It owns the window, panes, and routing. It places
   a browser **overlay** on that pane and talks to an **engine helper**.
3. **`ah-chromiumd` (or webkit / ladybird) is the engine.** It owns a **tab**—a
   real document instance—and a render surface the host can composite.
4. The engine reports readiness, geometry context, URL, title, and load state.
   The host draws the page into the pane. Chrome (URL bar, modes) stays in the
   product UI, not in a random floating browser window.

The rule of thumb:

- **Clients speak pane.**
- **Engines speak tab.**
- **The host binds the two.**

If you only remember one thing about TermSurf, remember that.

## The cast

| Role   | Shipped binary                               | Job                                                        |
| ------ | -------------------------------------------- | ---------------------------------------------------------- |
| Host   | `ahterm`                                     | Panes, compositing, TermSurf routing                       |
| Client | `ahweb`                                      | Open URLs / drive browser panes from a tool                |
| Engine | `ah-chromiumd`, `ah-webkitd`, `ah-ladybirdd` | Real browser process for a profile                         |
| Shell  | `ahsh`                                       | Astrohacker Shell—the shell product, not the browser spine |

Engine selectors for `ahweb` are family names: `chromium`, `webkit`,
`ladybird`. **Gecko / `ah-geckod` is not released** yet; the protocol leaves
room for it. There is no meta `ah` dispatcher. Reserved for later:
`ahwallet`.

Install story today: one Homebrew cask, Apple silicon, **Astrohacker
Terminal**—see [Terminal docs](/docs/terminal) and [Web docs](/docs/web).

```bash
brew tap astrohackerlabs/astrohacker
brew trust astrohackerlabs/astrohacker
brew install --cask astrohacker
```

That lands **Astrohacker Terminal.app** in `/Applications`, with PATH tools
including `ahterm`, `ahweb`, `ahsh`, and the engine helpers.

## Two pipes: sockets and protobuf

### Unix domain sockets

Host and client do not open a public TCP port for this. They use a **Unix
domain socket**: local IPC, a path on the machine, not “listen on the
internet.”

The client finds the host through the environment (notably
`TERMSURF_SOCKET`). Same idea for other TermSurf-adjacent session variables
like pane id. Local, fast, private to your Mac.

### Protocol Buffers

The wire language is **protobuf**, defined in `termsurf.proto`. Every frame is
a **`TermSurfMessage`**: an envelope whose payload is exactly one typed
variant—create a tab, move the mouse, report the URL, answer a query.

Why not free-form JSON per tool?

- One schema for Zig/Rust/C++ sides of the stack.
- Compact frames when input and page events get noisy.
- A shared vocabulary so every new client does not invent its own dialect.

You do not need to love protobuf to use Terminal. You need to know it is the
**contract** between host, clients, and engines.

## Messages as jobs (not tag numbers)

Think in **intents**, not field IDs.

**Session.** Client says hello; host replies with what it can do. Host signals
when a browser connection is ready for that work. Pane mode can flip between
browsing and not.

**Put a browser on a pane.** Client asks the host to place or update an
**overlay** (geometry, URL, profile, engine hints). DevTools gets its own
overlay path. Splits are “open another region,” still host-owned layout.

**Tabs and surfaces.** Host tells the engine to create, resize, or close a tab.
Engine answers with ready state and **surface / layer context** so the host can
composite the page into the pane (on macOS, the path you care about is real
compositing—not a screenshot loop).

**Input.** Keys, mouse, scroll, focus: host → engine, so the page receives what
you did in that pane.

**Page events.** Engine → host: URL, title, loading, cursor, link targets,
whether back/forward/refresh make sense. That is how the chrome stays honest
while the engine owns the document.

**Navigation as a product.** Back, forward, and refresh are first-class
actions—not only “set this URL string.” State messages tell the UI what is
available.

**Queries and polish.** List tabs, ask for last URL or DevTools info,
JS dialogs, HTTP auth, console lines, renderer crash signals. Some of that is
product chrome; some of it is automation harness. Same protocol family.

We chose this set because a **multi-process, multi-engine browser in a
terminal** needs exactly these seams. Not “RPC for everything.” Not a single
WebView stuffed into every CLI.

## Who talks to whom

```text
  ahweb  ──►  ahterm  ──►  ah-chromiumd / ah-webkitd / ah-ladybirdd
    ▲            │                    │
    └────────────┴──── events / replies ──┘
```

| Direction         | Why                                                                       |
| ----------------- | ------------------------------------------------------------------------- |
| **Client → host** | Ask for overlays, navigation, splits, queries without embedding an engine |
| **Host → engine** | Create/resize/close tabs; inject input; drive load and navigation         |
| **Engine → host** | Register, report surface and page state, surface dialogs/crashes          |
| **Host → client** | Hello/ready, mode, query answers—enough state to run chrome or automation |

Dialog and auth replies close the loop when something outside the sandboxed
page must answer a prompt. The host stays in the middle so the engine never has
to know your pane layout, and the client never has to own a browser binary.

## Why multi-process

Real engines are large, crashable, and security-sensitive. Isolating them is not
optional if you want Chromium-class behavior in a product window.

Multi-process TermSurf also means:

- **Many clients, one host.** `ahweb` today; other tools and apps later—same
  language.
- **No Chromium-in-every-CLI.** The install stays one Terminal plus helpers, not
  a browser fork per command.
- **Engine swap without rewriting clients.** Pick `chromium`, `webkit`, or
  `ladybird`; the client still speaks pane-level intent.

In-process WebViews are simpler demos. They are a different product. We wanted
**real engines** in panes. That forced a protocol.

## What to do next

1. Install on Apple silicon with Homebrew:

   ```bash
   brew tap astrohackerlabs/astrohacker
   brew trust astrohackerlabs/astrohacker
   brew install --cask astrohacker
   ```

2. Open **Astrohacker Terminal**, open a shell pane, and run
   `ahweb https://example.com` (add `--browser webkit` or `ladybird` when you
   want to feel the multi-engine claim).
3. Read [TermSurf protocol](/docs/termsurf) if you implement a client or care
   about the full message list.
4. Read [Web](/docs/web) for the product tool surface and
   [Terminal](/docs/terminal) for the host.

The point of TermSurf is boring on purpose: **one language** so a real browser
and a real terminal can share a window without inventing a new wire format
every time we add a tool. When `ahweb` works, that language is doing its job.
]]></content:encoded>
            <author>Ryan X. Charles</author>
        </item>
        <item>
            <title><![CDATA[Astrohacker 0.1.47: Rounded Panes, Real Gaps, Welcome to the Internet]]></title>
            <link>https://astrohacker.com/blog/2026-07-18-astrohacker-0-1-47</link>
            <guid isPermaLink="false">https://astrohacker.com/blog/2026-07-18-astrohacker-0-1-47</guid>
            <pubDate>Sat, 18 Jul 2026 22:00:00 GMT</pubDate>
            <description><![CDATA[Field notes from 0.1.37 through 0.1.47: card-like multi-pane chrome, engine tip upgrades, ahapp out of the package, and a cypherpunk welcome splash.]]></description>
            <content:encoded><![CDATA[
On [July 17 we field-noted 0.1.29 through 0.1.37](/blog/2026-07-17-astrohacker-0-1-37):
stock Terminal defaults (TokyoNight, borders, font, keybinds, ahsh, XDG), zsh
under ahsh for traditional mode, and quieter ahweb chrome.

A day later the install line is still **one cask**, still **Apple silicon**,
still **The Agentic Hacker’s Terminal**. What changed is how the **window**
reads when you split it—and what you see when the product opens its front door
on the web.

This post is the user-facing field notes from **0.1.37 through 0.1.47**.

## The short version

- **Multi-pane looks like a product** — every split pane gets **rounded borders
  on all four corners**, not square strokes under a rounded window.
- **Real air between panes** — `split-pane-gap` (default **4**) is empty margin,
  not a thicker black paint bar. The 1 pt drag hairline matches **theme
  background** when you leave `split-divider-color` alone.
- **Load chrome fits the pane** — the surface progress bar stays inside the
  rounded content box and picks colors from the **theme palette**.
- **ahapp is out** — no TermSurf “app host” PoC in the Terminal package story.
  Terminal + shell + web engines. Full stop.
- **Fork tips moved** — Chromium, WebKit, Ladybird, Ghostty, and the shell stack
  (including Nushell **0.114**) got release-gated updates through the line.
- **Welcome to the Internet** — default host splash at
  [astrohacker.com/welcome](https://astrohacker.com/welcome); the marketing
  site went **dark-only** with GlyphRain and glass cards.
- **Line** — **0.1.38 … 0.1.47** on the usual tap.

If you only remember one sentence: **upgrade, split a few panes, and the
window should finally look like one UI—not a grid of sharp rectangles with a
black trench between them.**

## Multi-pane that reads as cards

0.1.37 already turned split borders **on** by default and stopped dimming
inactive panes. That was necessary. It was not enough.

On modern macOS the window itself is rounded. Our borders were still drawn as
**square strokes**. Outer corners clipped wrong. Internal T-junctions looked
like office cubicles, not panes in a serious host.

We fixed the geometry: **all four corners of every split pane** use a continuous
radius—window-matched when `split-border-corner-radius = auto`, square when you
set `0`, or a fixed point size when you set a number. Content and unfocused
overlays clip **concentric** with the stroke so pixels do not square-fill past
the border band.

### Gap is air, not paint

With borders on, the next failure mode was the **seam**. A one-pixel dark
divider is easy to ignore. Making it “thicker” by painting a wider
`split-divider-color` rectangle is how you get a **black trench that sits on
top of the borders**—we tried that path, rejected it, and shipped the other
model.

**`split-pane-gap`** (default **4**, clamp `0`…`20`) reserves **empty layout
space** between pane frames. The painted divider stays a **1 pt** hairline for
drag. When `split-divider-color` is unset, that hairline uses the **theme
background**—not a darkened near-black—so the seam blends and the full rounded
border stays visible.

Want the old tight hairline-only layout? Set `split-pane-gap = 0`. Want a
visible accent seam? Set `split-divider-color` explicitly.

### Progress bar in the pane

OSC / load progress on a surface used to ignore the rounded clip and use
system accent colors. It now lives in the **inset content box** with the same
inner radius math as the terminal surface, and it reads palette indices that
track the theme (cyan / red / yellow family with sane fallbacks).

Small thing. Multi-engine windows make it obvious when chrome is wrong.

## Leaner package

Earlier posts already cut the **editor** out of the cask. This line cut the
**ahapp** TermSurf app-host PoC out of the product build and release story.
You still get:

- **Astrohacker Terminal** (`ahterm`)
- **ahsh**
- **ahweb** and the engine helpers

You do not get a second half-product pretending to be part of the same install.
If it is not Terminal, Shell, or Web in this window, it is not in this cask.

Build scripts now treat **`ahterm`** as the primary component name (`aht` still
aliases for muscle memory). That is hygiene, not a feature—but naming is part
of not lying to yourself about what you ship.

## Fork tips as product quality

0.1.38–0.1.47 is not only chrome. We ran release-gated updates on the engines
and host:

- **Chromium**, **WebKit**, **Ladybird** tips pinned and rebuilt for ship
- **Ghostty** tip advanced on the product branch series
- **Shell** stack moved with **Nushell 0.114** and exit-code fixes so `ahsh`
  stays honest under the new port

Users do not install “a pin.” They install a cask that either builds engines
cleanly or wastes a weekend. This line was a lot of the second kind of work so
you do not have to do it.

## Welcome to the Internet

The Terminal’s default homepage is no longer a generic TermSurf welcome. It
opens **[astrohacker.com/welcome](https://astrohacker.com/welcome)**: full-bleed
splash, dark only, **Welcome to / The Internet**, tagline **Advanced
Communications Network for Planet Earth**, slogan **Hack the Universe**, CTA
into docs.

The rest of the marketing site caught up: **dark-only** Tokyo Night, shared
**GlyphRain**, glass cards so rain shows through, wider shell for heroes, prose
measure for reading, unified **ASTROHACKER** wordmark. We fixed a stupid SPA
bug where `/welcome` flashed **404** on refresh because the route was not
prerendered and the hydrate shell was literally the 404 page. That should never
have shipped; it is gone.

This is not “we redesigned for brand guidelines.” It is: when an agent or a
human lands in the product window, the first page should feel like the same
company that put real browsers next to the shell.

## How to get it

Still one story:

```sh
brew tap astrohackerlabs/astrohacker
brew trust astrohackerlabs/astrohacker
brew install --cask astrohacker
```

Or upgrade if you already have it. App lands in
**Astrohacker Terminal.app**. Public CLIs: `ahterm`, `ahsh`, `ahweb` (plus
engine helpers). **Apple silicon** only. No editor SKU. No second cask.

Line covered here: **0.1.38 through 0.1.47**.

## Closing

We spent this stretch making multi-pane feel intentional—rounded cards, real
gaps, theme-native load chrome—and making the front door match the product
instead of a leftover PoC domain. The engines and shell underneath moved too,
because a pretty border on a stale fork is still a stale fork.

Split a window. Open a couple of engines. If it still looks like duct tape, tell
us. If it finally looks like one terminal that happens to run the web, that was
the point.
]]></content:encoded>
            <author>Ryan X. Charles</author>
        </item>
        <item>
            <title><![CDATA[Astrohacker 0.1.37: Opinionated Defaults, Zsh Under the Hood]]></title>
            <link>https://astrohacker.com/blog/2026-07-17-astrohacker-0-1-37</link>
            <guid isPermaLink="false">https://astrohacker.com/blog/2026-07-17-astrohacker-0-1-37</guid>
            <pubDate>Fri, 17 Jul 2026 22:00:00 GMT</pubDate>
            <description><![CDATA[Field notes from 0.1.29 through 0.1.37: stock Terminal defaults (theme, borders, font, keybinds, ahsh, XDG), zsh under ahsh, and cleaner ahweb chrome.]]></description>
            <content:encoded><![CDATA[
On [July 17 we field-noted 0.1.17 through 0.1.29](/blog/2026-07-17-since-astrohacker-0-1-17):
real browser toolbar, shell less leaky, install path less aspirational, and the
**editor cut out of the cask**.

A few releases later the install line is still **one cask**, still **Apple
silicon**, still **The Agentic Hacker’s Terminal**. What changed is the **blank
canvas**. Stock Astrohacker Terminal used to open like a fresh Ghostty with
product engines bolted on. Now it opens more like a setup someone already
lived in for a week—on purpose.

This post is the user-facing field notes from **0.1.29 through 0.1.37**.

## The short version

- **Stock Terminal has opinions** — TokyoNight, visible theme-relative split
  borders, no dimming of inactive panes, JetBrainsMono Nerd Font at 12pt, and a
  split/tab keybind map baked in.
- **Default shell is ahsh** — not via “hope Dock has Homebrew on PATH,” but via
  absolute paths (`/opt/homebrew/bin/ahsh`, then `/usr/local/bin/ahsh`), with
  the normal system shell if neither is there.
- **Session config home** — when unset, we inject `XDG_CONFIG_HOME=$HOME/.config`
  so children (including the shell) share a sane layout on macOS.
- **Traditional mode is zsh** — bootstrap and alt mode load the shell macOS
  users actually configure; **nu stays the default** interactive mode;
  **Shift+Tab** is called out on the banner.
- **Ahweb chrome** — rounded boxes stay rounded when disabled; disabled is a
  **color** change, not a geometry flip.
- **Line** — **0.1.30 … 0.1.37** on the usual tap.

If you only remember one sentence: **upgrade, open from the Dock once, and a
stock install should look and behave less like an empty config file.**

## Stock Terminal defaults

This window was mostly me taking the personal config I actually run and asking:
what should every new user get without pasting a gist?

### Theme: TokyoNight

Ghostty’s upstream default is “no named theme”—hard-coded colors that are fine
and forgettable. We default the product theme to **TokyoNight** (exact resource
name, capital T and N). Light and dark both point at that face unless you set
`theme` yourself.

### Splits that read as UI

Inactive panes used to **fade**. Borders used to be off unless you opted in.
That combination is how multi-pane terminals become a guessing game.

Stock defaults now:

- **Split border width 2**
- Unset focused / unfocused border colors fall back to theme **palette[6]** /
  **palette[8]** (cyan / bright black on TokyoNight)
- **Unfocused opacity 1** — no dim overlay; **borders** mark focus

If you liked the fade, set `unfocused-split-opacity` below 1. Explicit border
colors and `split-border-width = 0` still work.

### Type and chords

- **Font:** JetBrainsMono Nerd Font at **12pt** (you still need the face
  installed on the machine).
- **Keybinds** (macOS; `cmd` = Super), including:

  - `cmd+h/j/k/l` — new split left / down / up / right
  - `ctrl+h/j/k/l` — focus split
  - `ctrl+alt+arrows` — resize
  - `ctrl+shift+h/l` and arrows — tabs
  - `ctrl+shift+z` — zoom split

Last-wins on shared triggers: product defaults replace some upstream defaults
(for example `cmd+k` is no longer clear-screen). **`cmd+h`** can still lose to
macOS Hide—that is the OS, not a promise we can fully keep.

This is not a settings panel. It is **baked defaults**. Your config still wins
when you set the keys.

### Shell process: ahsh even from the Dock

Homebrew puts `ahsh` on PATH for **shells you launch from a configured
environment**. A **`.app` launched from the Dock** does not magically inherit
that PATH.

So we do not default to bare `command = ahsh` and pray. At finalize we try, in
order:

1. `/opt/homebrew/bin/ahsh`
2. `/usr/local/bin/ahsh`

First path that exists becomes the default command. If neither exists, we fall
through to Ghostty’s normal system shell story (`SHELL` in CLI contexts, passwd
shell, then a last-resort `sh`).

We also inject **`XDG_CONFIG_HOME=$HOME/.config`** when neither the process env
nor your config already set it—so session children share XDG layout without
hardcoding a username. Pre-set env and explicit `env =` still win.

## Shell: zsh where macOS actually lives

`ahsh` still defaults to **nu** for interactive work. What changed under the
hood is the **traditional** path and the **bootstrap** path.

macOS users put PATH, brew, nvm, and friends in **zsh** files—not in a museum
`bash` 3.2 login. We switched the external worker from bash to **zsh**: login
plus an explicit path that still picks up **`.zshrc`-class** setup so a first
download is not a blank PATH.

Mode cycle is **nu ↔ zsh**. The startup banner hints **Shift+Tab**. Docs live
under [Shell](/docs/shell).

If your muscle memory was “I need my zsh env before nu feels useful,” that is
closer to automatic now.

## Ahweb chrome: one geometry

Browser-in-pane chrome had a small lie: disabled nav buttons could look like a
**different shape** of box than enabled ones. Stock TUI now keeps **rounded**
frames for the chrome that matters (nav, URL, viewport). Disabled is **color**,
not a square-vs-rounded flip. Mode focus still reads through border color, not
border type.

Same product surface—less “three widgets from three demos.”

## Install line (still boring on purpose)

Still one Homebrew cask, still Apple silicon, still ad-hoc codesign and
`brew trust` as **tap** trust—not Apple notarization. Engines are still heavy
on first launch because they are real.

This window also included WebKit packaging work (sandbox exclusion archive) so
“release builds WebKit” stays a sentence we can finish. That is reliability,
not a new engine brand.

Current line at time of writing: **0.1.37**.

```bash
brew tap astrohackerlabs/astrohacker
brew trust astrohackerlabs/astrohacker
brew install --cask astrohacker
# or
brew update && brew upgrade --cask astrohacker
```

Smoke:

```bash
ahterm +version
ahsh --version
ahweb --version
```

Open the app **from the Dock once** after upgrade. That is the PATH story you
are actually testing—not only a shell where Homebrew is already on `PATH`.

## What we did not ship

Same honesty bar as 0.1.17 / 0.1.29:

- **Gecko** is not a product engine on the cask.
- **Wallet**, mobile, web Economy, English shell product, AI marketplace,
  first-party hosted models — direction or later, not “install and use today.”
- **Notarized / Developer ID** shipping is still ahead.
- We did **not** promise your old personal keybinds are unchanged. Some
  product defaults intentionally override upstream Ghostty chords.

Internal monorepo workspace reorg and agent breadcrumbs shipped in this
window. They make the tree easier to build; they are not a user feature.

## Who this is for

Unchanged: agentic builders on **Apple silicon** who live in a terminal and
hate Cmd-Tab tax for “open the docs / dashboard / OAuth page.”

If you installed for **browsers in panes**, upgrade—defaults and shell
bootstrap are less of a DIY kit.

If you rely on **upstream Ghostty’s stock chords and empty theme**, read the
defaults section: the product is more opinionated now. Override what you
dislike; that is still a config file, not a trap.

## What to do

```bash
brew update
brew upgrade --cask astrohacker
```

Cold-launch from the Dock. Confirm TokyoNight, split borders, **ahsh**, and
that tools from your zsh config show up in nu after bootstrap.

If JetBrainsMono Nerd Font is missing, install the face or set `font-family`.
If ahsh is missing from the cask PATH layout, that is a bug report—the absolute
path search should still hit the Homebrew bin we ship.

Read the [docs](/docs). Remove personal config lines that only duplicated
these defaults if you want a thinner file.

We will keep shipping the same way: **focus the Terminal wedge, bake what
works, prove it on a real install, cut the rest.**
]]></content:encoded>
            <author>Ryan X. Charles</author>
        </item>
        <item>
            <title><![CDATA[Astrohacker 0.1.29: Terminal Focus, Real Toolbar, Editor Gone]]></title>
            <link>https://astrohacker.com/blog/2026-07-17-since-astrohacker-0-1-17</link>
            <guid isPermaLink="false">https://astrohacker.com/blog/2026-07-17-since-astrohacker-0-1-17</guid>
            <pubDate>Fri, 17 Jul 2026 20:00:00 GMT</pubDate>
            <description><![CDATA[What shipped from 0.1.17 through 0.1.29—browser Back/Forward/Refresh, shell hardening, install repairs, and why the Terminal no longer includes an editor.]]></description>
            <content:encoded><![CDATA[
On [July 13 we announced 0.1.17](/blog/2026-07-13-astrohacker-0-1-17): real
browser engines in panes next to your shell on Apple silicon, one Homebrew
cask, early-adopter honesty.

A few days later the install line is still **one cask**, still **Apple silicon**,
still **The Agentic Hacker’s Terminal**. The workbench is not the same. This
post is the field notes from **0.1.17 through 0.1.29**—what got better, what we
ripped out, and what you should expect when you upgrade.

## The short version

- **Browser panes grew a real toolbar** — Back, Forward, Refresh that work in
  the product window, not as science experiments.
- **Shell got less leaky** — startup and alt-mode behavior that was eating
  sessions got fixed and re-qualified on real installs.
- **Install quality stopped being aspirational** — legal package, WebKit
  packaging and quarantine fixes, coherent public releases instead of “hope
  the archive matches the story.”
- **The editor is gone** — no Helix-based Terminal editor, no `ahed` on PATH,
  no “editor is included” marketing. Terminal + shell + web engines. Full stop.

If you only remember one sentence: **we doubled down on the multi-engine
terminal and stopped shipping a second product inside the same install.**

## Why cut the editor

0.1.17 listed four surfaces in the install story: Terminal, Shell, Editor, Web.
That was honest about how the tree was built. It was a bad focus tax.

A Helix fork is a product: runtime, grammars, themes, packaging, health checks,
docs, release gates. Maintaining that _and_ three real browser engines _and_ a
host terminal is how you spend a month polishing the wrong wedge.

Astrohacker’s bet is the **agentic workbench**: shell and agents in one window
with **real browsers** (Chromium, WebKit, Ladybird) and real profiles—not “also
a modal editor because the monorepo had one.”

So we deleted it. Fork, patches, packaging, cask install, current docs and
marketing. Recovery is git history if we ever need the corpse. History posts
that mention the editor stay as history. New installs do not get an editor
binary.

**Not a rename.** Not “coming back next week under a cooler name.” Removal.
Future editors, if any, get their own product design—not a silent revive of
the old PATH name.

## Browser panes that behave like a browser

The 0.1.17 post sold engines in panes. Users still needed **chrome that
respects history**.

Since then we shipped and product-qualified:

- **Back** — per engine, through the host chrome, not a pretend button.
- **Forward** — same contract the other direction.
- **Refresh** — including idle icon layout that does not look half-drawn.

Under the glass we also pushed **shared native input** (text, pointer paths,
editing responder work) so panes feel less like three unrelated demos glued
into one window.

And a nasty layout bug: **split views that swallowed the web surface**. If you
split a pane and the page vanished into the void, that was real. It is fixed
and checked across engines. Your split bindings are supposed to stay yours.

## Shell: stop the session tax

Right after 0.1.17 we hit a **shell startup / capture** problem that could
wreck a session before you noticed. That landed as a verified hotfix path
(**0.1.19** era) and follow-on work: safer startup, configured alt-mode
switching that does not lie about which shell you meant.

If your muscle memory is “open Terminal, live in `ahsh`,” that path is more
boring now. Boring is the goal.

## Install and release: make “Homebrew” mean something

Early post-0.1.17 life included the unglamorous work:

- **CLI identity** — what ships on PATH is the Terminal set (`ahterm`, `ahsh`,
  `ahweb`, `ahapp`, engine helpers). No editor. No meta-`ah` dispatcher.
- **Legal package** in the release tree (LICENSE, NOTICE, trademarks, third-party
  artifacts) so the archive is not a bag of binaries with a shrug.
- **WebKit packaging** — staged links, signature expectations, quarantine /
  xattr cleanup so “installed cask” and “works after first launch” are closer
  to the same sentence.
- **Release restoration** after regressions—engines and public installs repaired
  through a sequence of public versions (**0.1.20–0.1.23**), not abandoned.
- **One-command Homebrew release** orchestration so the next patch is not a
  ritual of forgotten steps.
- **Preserve build caches** on routine release so WebKit/Chromium/Ladybird do
  not full-rebuild because someone confused “release mode” with “delete the
  universe.”
- **First-party crate versions** track the cask version on release. Forks stay
  out of that bump.

Current line at time of writing: **0.1.29** via the usual tap.

```bash
brew tap astrohackerlabs/astrohacker
brew trust astrohackerlabs/astrohacker
brew install --cask astrohacker
# or
brew update && brew upgrade --cask astrohacker
```

Smoke after upgrade:

```bash
ahterm +version
ahsh --version
ahweb --version
```

You should **not** expect `ahed` anymore. If an old install left editor config
under `~/.config/astrohacker/editor`, uninstall zap may still clean it; the
product does not reinstall it.

**Still true from 0.1.17:** ad-hoc codesign, `brew trust` is tap trust not Apple
notarization, first launch can be heavy because engines are real.

## Website and slogan (quick)

- Slogan is **The Agentic Hacker’s Terminal** again—we briefly tried a shorter
  form and put the agentic word back where it belongs.
- Public docs got a craft pass (Terminal-first, less packaging lecture).
- About page carries the manifesto energy; install cards say **Astrohacker
  Terminal**, not “bundle of SKUs.”
- Brand monogram work landed for assets that need a sharp mark.

Process side, if you care how the sausage ships: we kept running **Issues and
Experiments** hard on this window—navigation, splits, release, editor removal
all went through design/result gates. That is [how we get agents solving
defined work overnight](/blog/2026-07-15-how-to-get-ai-solving-problems-for-you-while-you-sleep),
not a claim that the product is finished.

## What still is not shipped

Same honesty bar as 0.1.17:

- **Gecko** embedding is research, not a product engine on the cask.
- **Wallet**, mobile, web app, English shell product, AI marketplace, Economy
  flows — direction or later work, not “install and use today.”
- **Notarized / Developer ID** shipping is still ahead.

We did a lot of Gecko _parity experiment_ work in this window. That is
engineering progress, not a download button.

## Who this is for

Unchanged audience: agentic builders on **Apple silicon** who already live in
the terminal and hate Cmd-Tab tax for “open the docs / dashboard / OAuth page.”

If you installed 0.1.17 for **browsers in panes**, upgrade. The toolbar and
install path are less of a science fair.

If you installed 0.1.17 primarily for the **included modal editor**, this line
will disappoint you on purpose. Use the editor you already trust; we are not
competing there right now.

## What to do

```bash
brew update
brew upgrade --cask astrohacker
```

Read the [docs](/docs). Open a pane. Hit Back when you mean Back.

If something still vanishes when you split, or an engine fails after upgrade,
that is a bug report—not a lifestyle choice. We will keep shipping patches
with the same rule we used on the editor: **focus the Terminal wedge, prove
it, cut the rest.**
]]></content:encoded>
            <author>Ryan X. Charles</author>
        </item>
        <item>
            <title><![CDATA[How to Get AI Solving Problems For You While You Sleep]]></title>
            <link>https://astrohacker.com/blog/2026-07-15-how-to-get-ai-solving-problems-for-you-while-you-sleep</link>
            <guid isPermaLink="false">https://astrohacker.com/blog/2026-07-15-how-to-get-ai-solving-problems-for-you-while-you-sleep</guid>
            <pubDate>Wed, 15 Jul 2026 18:00:00 GMT</pubDate>
            <description><![CDATA[Issues and Experiments: a harness-agnostic loop so agents keep solving real work overnight—and across days—whether the implementer is Codex, Grok, Claude Code, or Cursor.]]></description>
            <content:encoded><![CDATA[
You write down what “solved” means. You walk away. In the morning the issue has
a plan commit, a result commit, tests that ran, and a second agent that tried to
kill the work before it landed.

That is the product of a habit, not a vibe session.

We run that habit at Astrohacker as **Issues and Experiments** (InE). It is how
we ship small brand fixes in an afternoon and how we keep multi-day engine and
release work coherent when no human is mid-loop. This is not a pitch for a new
coding model. It is a way to get the agents you already use—Codex, Claude Code,
Grok, Cursor, and friends—to keep solving **defined** problems without you
babysitting the chat.

If you want the original lifecycle manifesto, read [Building Software While You
Sleep](/blog/2026-06-01-building-software-while-you-sleep). This post is the
field guide: same loop, different diameters, any harness, and a workbench that
matches the idea.

## The only job that is still yours

You do not “prompt harder.” You **specify**.

An issue that can run overnight needs three things written down before anyone
types code:

1. **Goal** — one coherent outcome, not a wish list.
2. **Verification** — commands and observations that would convince a skeptic
   the goal is met.
3. **Guardrails** — what is out of scope, what must stay honest, what must not
   be rewritten.

Once that exists, solving becomes mechanical enough that an agent can own the
middle of the loop. You are not the implementer. You are the person who made
“done” falsifiable.

## Issues and Experiments, one screen

**Issue** — a folder with a README: goal, verification, constraints, status.
Durable. In git. Not a Discord message.

**Experiment** — one decision-complete step toward the goal. Design it. Get it
reviewed. Commit the plan. Implement only then. Verify. Record Pass / Partial /
Fail. Get the result reviewed. Commit the result. **Then** design the next one.

You never list experiment 1 through 12 up front. Experiment N’s result is what
tells you what N+1 should be. Failure is not drama. It is information.

**Adversarial review** — a second agent, cold context, preferably a different
harness when you can. Design review before implementation. Completion review
before the result commit. Marking your own homework is how slop ships overnight.

InE is **not** a coding tool. It does not replace Codex, Claude Code, Grok, or
Cursor. It is the honesty and progress layer those tools plug into. The agents
write the code and run the tests. The issue file owns the truth.

## Same loop, different diameter

The machine does not change when the problem shrinks or grows. Only the diameter
does.

**Hours.** Restore a slogan, fix a CLI identity leak, close a one-surface copy
mistake. One experiment. Still: design review, plan commit, implement,
`test:whatever` that actually gates the claim, completion review, result commit.
Small work with real positioning risk does not get a free pass because it is
“just marketing.”

**Days.** Multi-engine parity, release restoration, long host work. The issue
stays open. Experiments stack. Sessions end and restart. What survives the night
is not a 40-turn chat transcript—it is the issue README, the experiment files,
and the commits that mark plan vs result. Morning context is `git log` and a
markdown notebook, not “remind the model what we were doing.”

That is why sleep works. Resume is reading the record, not re-explaining the
universe.

## Two receipts

### Multi-day: work that refuses to fit in one sitting

We have used InE on terminal and engine work that spans multiple days: open
issue, clear “done,” experiments that cannot all be designed on day one because
day one’s failures rewrite day two. Orthogonal review keeps implementers from
drifting when the human is offline. The proof is in the `issues/` tree and the
commit history—not in a slide about “AI productivity.”

What would break without the loop: scope expands every time an agent hits a
wall; “almost works” gets declared done; the chat that held the plan dies with
the session.

### Small: still specify, still review

We have also used the same shape on problems that take a single afternoon—brand
and site copy, install surface honesty, slogan and title lines that must match
what we actually market. One decision-complete experiment. Same dual review.
Same two commits.

What would break without the loop: a “quick” agent edit that leaves canon,
homepage, and CI disagreeing—or a short slogan that sounded fine until you
remembered why the long form existed.

Tiny diameter. Same machine.

## Use any coding harness

InE does not care who wrote the patch.

- **Implementer** — Codex, Claude Code, Grok, Cursor, whatever is sharp today.
- **Reviewer** — a cold second look; a different harness when you can (orthogonal
  review). Fresh context matters more than brand loyalty.
- **System of record** — the issue and experiment files in the repo.

Swap models next month. The issue still closes the same way: verification
passes, reviews pass, commits exist, status flips to closed.

If your process only works inside one vendor’s chat product, you do not have a
process. You have a subscription.

## Anti-patterns (steal these as rules)

- Designing a long experiment list before the first result exists.
- Skipping design review “because it’s small.”
- Treating chat as the system of record.
- Combining plan and result into one commit.
- Expanding scope when an experiment fails instead of writing what you learned.
- Declaring victory without the verification commands you wrote when you were
  sober.

## When not to bother

Do not open an issue for a typo with no risk.

Do not automate pure exploration until you can say what “done” means. First write
the goal. Then open the issue. Then sleep—or don’t, but at least the machine
knows the target.

## The workbench we run it in

If the loop is harness-agnostic, the host should not lock you to one chat
window and a separate browser.

**Astrohacker Terminal** is the native app we use for that work: a serious
terminal host with **multiple real browser engines** and **multiple profiles**
in the same window, plus the shell, editor, and web tools that ship in the same
install. Run the coding agents you already use—Codex, Grok, Claude Code, Cursor,
and friends—next to real web panes, not in a pile of unrelated apps.

InE is still the method. The Terminal is the place the method lives when agents
need a shell and a browser at the same time.

Apple silicon, Homebrew:

```sh
brew tap astrohackerlabs/astrohacker
brew trust astrohackerlabs/astrohacker
brew install --cask astrohacker
```

Steal the process even if you never install us. Install us if you want the
workbench built for the same idea.

Set the goal. Let the agents iterate. Wake up to receipts.
]]></content:encoded>
            <author>Ryan X. Charles</author>
        </item>
        <item>
            <title><![CDATA[Why Ghostty Is the Greatest Terminal]]></title>
            <link>https://astrohacker.com/blog/2026-07-14-why-ghostty-is-the-greatest-terminal</link>
            <guid isPermaLink="false">https://astrohacker.com/blog/2026-07-14-why-ghostty-is-the-greatest-terminal</guid>
            <pubDate>Tue, 14 Jul 2026 16:00:00 GMT</pubDate>
            <description><![CDATA[Ghostty is what a modern terminal should feel like—native, fast, and serious. Here’s why, and what we built on top of it.]]></description>
            <content:encoded><![CDATA[
You live in a terminal now more than you did five years ago.

Not because nostalgia won. Because agents run there. Shells run there. Editors,
test runners, `git`, and half the control plane of modern software run there.
The window you keep open for twelve hours is not a browser with a dock icon. It
is a grid of panes that refuse to become chrome.

So the terminal has to be great again. Not “pretty.” Not “configurable until it
becomes a second operating system.” **Great**—native, fast, correct, and boring
in the ways that let you forget it exists.

**Ghostty is the greatest terminal** under that definition.

## What “greatest” means here

I am not ranking every escape sequence ever implemented. I am not scoring Sixel
trivia or remote-mux Olympics.

For people who live in the shell—including people who run coding agents all
day—great means:

1. **Native where you are.** On macOS, it should feel like a macOS app. On
   Linux, like a real desktop citizen—not a cross-platform skin.
2. **Fast by default.** You should not notice the terminal under scroll, resize,
   or a noisy build.
3. **Modern terminal correctness.** True color, solid Unicode, shell
   integration, the stuff you only notice when it is broken.
4. **A real product.** Windows, tabs, splits, menus, settings—not a research
   renderer duct-taped to a PTY.
5. **Architecture that can last.** Core that is engineered, not a ball of glue.

Ghostty wins those. That is the claim.

## Native is not a theme

Most terminals ship one UI story and paint it on every OS. Ghostty does the
harder thing: **platform-native UI** with a shared core.

On macOS, Ghostty is a real Swift app—windowing, menus, settings, the
integration surface you expect from software that belongs on the machine. The
renderer talks **Metal**. Font discovery uses **Core Text**. That is not a
marketing bullet; it is the shortest path from “glyph” to “pixels on an Apple
Silicon laptop.”

On Linux, the GUI is its own first-class shell (GTK), with OpenGL acceleration.
Same product idea: native shell, shared engine.

The engine is **libghostty**—a Zig core exposed as a C-ABI library: terminal
emulation, fonts, rendering. The apps are consumers of that core. That split is
why Ghostty can feel native without forking the entire terminal state machine
per platform.

If you have ever used a terminal that _almost_ looks right on a Mac—menus that
feel foreign, fonts that feel slightly wrong, GPU path that is “Metal via three
translation layers”—you know why this matters. Ghostty is not almost.

## Speed is the absence of a feeling

The best terminal performance is invisible. You resize a split and the grid
keeps up. You flood the PTY with compiler output and the UI does not become a
slide show. You type, and the shell is the bottleneck—not the emulator.

Ghostty is built as a **GPU-accelerated** terminal from the ground up. Metal on
macOS. OpenGL on Linux. A heavily optimized parse path for the firehose of
bytes that real work produces. Dedicated rendering architecture instead of
“paint when we get around to it.”

You can always find a microbenchmark war online. Lived experience is simpler:
when the terminal disappears under load, you keep working. Ghostty is in that
class. That is table stakes for anyone who runs agents, watchers, and logs in
the same window for hours.

## A terminal, not a platform

Some emulators win by becoming everything: remote multiplexer, scripting host,
plugin economy, second desktop environment. Power exists there. So does
complexity tax.

Ghostty’s bet is different. It is a **terminal product**—tabs, splits,
keybindings, configuration, shell integration, modern protocols—without making
“embed a whole programming language in your config” the center of the story.
Configuration is first-class. The daily surface stays a terminal.

That restraint is a feature. When your day is already full of agents, editors,
and half-finished plans, the host should not demand a second career.

## Serious engineering

Ghostty is not a weekend wrapper around someone else’s VT parser with a glow
theme.

It is a full-stack terminal project: custom event-loop DNA, a real font stack,
platform renderers, a C-API boundary between core and GUI, and a public product
that people actually daily-drive. **libghostty** is the long game—an embeddable
modern terminal core so the hard work of emulation and rendering is not
re-solved by every app that needs a grid of cells.

You feel that seriousness in the details. Selection behaves. Scrollback holds
up. The app shell does not fight the OS. Upstream is active. The project treats
the terminal as infrastructure, not as a skin.

Great tools usually look like that: boring competence stacked high enough that
it becomes charisma.

## What Ghostty is not

Ghostty is not the winner of every checkbox on every platform on every day.

It is not a Windows-first product today—macOS and Linux are the shipping
story; Windows is a longer path. It is not trying to replace tmux-over-SSH as a
lifestyle. It will not match every graphics protocol or config dialect of every
legacy emulator.

If your primary requirement is “one binary, every OS, every protocol, Lua all
the way down,” you may pick something else and be happy.

If your requirement is **the best place to live in a shell on a modern Mac (or
Linux box)**—fast, native, correct, product-grade—Ghostty is the bar.

## Why this matters more now

Coding agents made the terminal the control plane again.

Claude Code, Codex, Grok, OpenCode, Pi—whatever you actually run—the loop is
pane-shaped. Repo in one split. Agent in another. Logs in a third. You need a
host that does not flake under that density. You need something that feels like
part of the computer, not a guest UI.

Ghostty is the greatest terminal for that life because it gets out of the way
without going dumb. Native craft. GPU path. Real app. Serious core. That is the
foundation you want under agent chaos.

## What we built on top

We did not want to rebuild a great terminal from scratch.

Astrohacker Terminal is built on Ghostty’s model as the host: the same bet on
native panes, speed, and a real macOS app shell. What we add is the thing Ghostty
is not trying to be—**real browser engines in the same window as the shell**.
Chromium, WebKit, Ladybird; multiple profiles; a page next to the agent that is
still working.

If you only need the greatest terminal, use [Ghostty](https://ghostty.org/).

If you want that foundation with browsers in the panes, install Astrohacker:

```bash
brew tap astrohackerlabs/astrohacker
brew trust astrohackerlabs/astrohacker
brew install --cask astrohacker
```

Docs live at [astrohacker.com/docs](https://astrohacker.com/docs).

The order is intentional. Ghostty first. Host second. The terminal had to be
great before anything else belonged in the window.
]]></content:encoded>
            <author>Ryan X. Charles</author>
        </item>
        <item>
            <title><![CDATA[Astrohacker 0.1.17: Real Browsers in Your Terminal]]></title>
            <link>https://astrohacker.com/blog/2026-07-13-astrohacker-0-1-17</link>
            <guid isPermaLink="false">https://astrohacker.com/blog/2026-07-13-astrohacker-0-1-17</guid>
            <pubDate>Mon, 13 Jul 2026 12:00:00 GMT</pubDate>
            <description><![CDATA[Multi-engine, multi-profile panes next to your shell on Apple silicon—install with Homebrew and keep coding agents, docs, and dashboards in one window.]]></description>
            <content:encoded><![CDATA[
You are mid-session on a MacBook Pro. Codex or Claude Code or Grok is grinding
through a change in one pane. Another pane has the repo. A third has whatever
you were editing before the agent rewrote it.

And the docs? The OAuth screen? The CI log that only renders as a web UI? Those
are still in a separate browser, three spaces over, cookies mixed with your
personal Gmail.

**Astrohacker 0.1.17 puts real browser engines in panes next to that work.**

Same window. Same flow. Chromium, WebKit, and Ladybird—each with isolated
profiles—beside the shell and editor you already live in.

This post is for early adopters who already treat the terminal as home base:
agentic builders on Apple silicon who run coding agents all day and are willing
to try something rough if it kills the Cmd-Tab tax.

## What 0.1.17 is

Astrohacker ships as **one desktop install**, not four consumer products.

You get:

- **Terminal** — the host app. Ghostty-based. Panes, tabs, and configuration
  you expect from a serious terminal, plus browser panes in the same window.
- **Shell** — included. Structured, Nushell-lineage tooling in a single binary.
- **Editor** — included. Modal Helix-style editing with language tooling
  in-process.
- **Web** — open a real engine in a pane from a shell command.
- **Engine helpers** — Chromium, WebKit, Ladybird. You do not day-drive these;
  the product does.

Platform for this release: **Apple silicon macOS**. If you are not on that,
this post is not your install path yet.

What is **not** in 0.1.17 as a shipped product surface:

- Gecko / Firefox embedding (`ah-geckod` is research, not released)
- Wallet
- Mobile, web app, marketplace, or “Economy” start flows

0.1.17 is early. It is usable. It is not pretending to be polished forever
software.

## Why agentic builders care

Coding agents already made the terminal the control plane. The missing piece
was the **web surface that still owns half of software work**.

With Astrohacker you can:

- Keep the **agent CLI**, the **repo**, and the **page you are verifying** in
  one window
- Use a **work profile** for GitHub / cloud consoles and a **personal profile**
  for everything else—without a second browser user ceremony
- Open the **same URL in Chromium, WebKit, or Ladybird** when something smells
  engine-specific
- Stay in flow when the agent says “check the docs” or “log into the dashboard”

Agents draft and edit. You still have to _see_ the web. That loop should not
require leaving the terminal.

## Install with Homebrew

Apple silicon MacBook Pro. Homebrew. One cask.

```bash
brew tap astrohackerlabs/astrohacker
brew trust astrohackerlabs/astrohacker
brew install --cask astrohacker
```

Upgrade later:

```bash
brew update
brew upgrade --cask astrohacker
```

Smoke checks after install:

```bash
ahterm +version
ahsh --version
ahed --version
ahed --health rust
```

You should see **0.1.17** (or the version the cask currently points at after an
upgrade). `ahed --health rust` should work without manually setting
`ASTROHACKER_EDITOR_RUNTIME`.

**What the install includes on PATH:** `ahterm`, `ahsh`, `ahed`, `ahweb`,
`ahapp`, plus engine helpers `ah-chromiumd`, `ah-webkitd`, and `ah-ladybirdd`.
There is no meta `ah` dispatcher. Reserved for later: `ahwallet`.

**Signing note (read this once):** install uses ad-hoc codesign and clears
quarantine. `brew trust` trusts the **tap**, not Apple notarization. Full
Developer ID / notarized shipping is still ahead. That is honest early-adopter
software, not a silent security claim.

First run can feel heavy. Engines are real engines. Warmup and disk use are
part of the deal.

## The workbench

Capability first. Identifiers second.

### Terminal (`ahterm`)

Open **Astrohacker Terminal**. That is the app. `ahterm` is the launcher on
PATH.

This is the host: multi-pane terminal work, plus browser panes that resize with
the layout. Native terminal features come from the Ghostty lineage. Astrohacker
adds the TermSurf protocol path, multi-engine profile servers, and the chrome
that keeps browser and shell panes readable together.

### Shell (`ahsh`)

`ahsh` is Astrohacker Shell—Shannon / Nushell family, packaged with Terminal.
Tooling lives in the binary instead of starting life as a plugin zoo.

It is structured when you want structured pipelines. It also has a **zsh alt
mode** when you need a familiar traditional subprocess without abandoning the
shell you launched (macOS-default env via zsh, not bash).

Config follows Nushell habits (`env.nu`, `config.nu` under your Nushell config
dir).

### Editor (`ahed`)

`ahed` is a Helix-based modal editor. Vim-ish keys. Language tooling and
syntax in-process. It ships with runtime assets so a normal Homebrew install
does not require you to invent environment variables first.

Useful checks: `ahed --version`, `ahed --health rust`.

### Web (`ahweb`)

This is the command you will actually type.

From a pane inside Astrohacker Terminal:

```bash
ahweb example.com
ahweb example.com --browser webkit
ahweb example.com --browser ladybird --profile work
```

`ahweb` draws the terminal chrome (URL bar, modes, status). The page itself is
a real engine surface composited into the pane—not a toy HTML renderer.

Modes are intentionally modal: Control for terminal keybindings, Browse for
keyboard/mouse into the page, Edit for the URL, Command for `:` commands.
That is the same muscle memory most of us already have from editors and
browsers that respect focus.

Engine selectors are family names: `chromium`, `webkit`, `ladybird`. Future
`gecko` is not a product claim yet.

### Apps (`ahapp`)

`ahapp` launches GTUI in-terminal apps when the Terminal pane environment is
present. Same product install. Smaller surface area than `ahweb` for most
people day one—know it exists when you need an app, not just a URL.

### Engine helpers

`ah-chromiumd`, `ah-webkitd`, and `ah-ladybirdd` are profile servers and embed
helpers. Prefer opening pages through Terminal / `ahweb`. Reach for the
helpers only when you are debugging packaging or engine paths.

## A multi-pane day

Here is the loop 0.1.17 is built for.

1. Open Astrohacker Terminal.
2. Pane A: your coding agent—Claude Code, Codex, Grok, OpenCode, Pi, whatever
   you actually use.
3. Pane B: `ahsh` in the repo the agent is touching.
4. Pane C: `ahed` on the file that just changed.
5. Pane D: `ahweb http://localhost:3000` (or the docs, or the provider
   dashboard) with `--profile work` if you want login isolation.

When the agent asks you to verify a UI, you do not leave. When the docs site
and the app disagree, you split panes. When WebKit and Chromium disagree, you
change `--browser` instead of installing a second browser lifestyle.

That is the product: **agents, code, and real web in one window.**

## What 0.1.17 is not

Short list so we keep trust:

- Not a promise that every site is perfect in every engine
- Not Gecko parity
- Not Wallet
- Not a multi-SKU store of “Shell Inc.” and “Editor Inc.”
- Not finished

It is a workbench release for people who install from a tap and send bug
reports with stack traces.

## What to do next

Install:

```bash
brew tap astrohackerlabs/astrohacker
brew trust astrohackerlabs/astrohacker
brew install --cask astrohacker
```

Then open Terminal, split a pane, and run:

```bash
ahweb example.com
```

Docs for components and engines live under
[astrohacker.com/docs](https://astrohacker.com/docs)—Terminal, Shell, Editor,
Web, Chromium, WebKit, Ladybird.

If you are already living with coding agents on Apple silicon, this is the
version to try: **0.1.17**, one Homebrew cask, real browsers where your agents
already are.
]]></content:encoded>
            <author>Ryan X. Charles</author>
        </item>
        <item>
            <title><![CDATA[Why Gecko Is the Hard One]]></title>
            <link>https://astrohacker.com/blog/2026-07-12-why-gecko-is-the-hard-one</link>
            <guid isPermaLink="false">https://astrohacker.com/blog/2026-07-12-why-gecko-is-the-hard-one</guid>
            <pubDate>Sun, 12 Jul 2026 16:00:00 GMT</pubDate>
            <description><![CDATA[Chromium, WebKit, and Ladybird can sit in a terminal pane. Gecko can too—eventually. Here is why Firefox is the awkward fourth engine, what we already proved, and what still counts as real support.]]></description>
            <content:encoded><![CDATA[
Astrohacker Terminal runs **real browser engines** in the same window as your
shell: Chromium, WebKit, Ladybird today, and Gecko on the long path. Same
protocol. Same “open a page beside the terminal” idea. Very different amount of
pain.

This is not a dunk on Firefox. Gecko is excellent software. It is also the
engine whose **desktop embedding story** was never written for people like us.
We learned that the expensive way—research, builds, experiments, and a few
honest dead ends.

## What “supported” means here

We are not shipping a Firefox skin. We need the same **product shape** the
other engines already have:

- A page loads in a **terminal pane**, not a random window somewhere on the
  desktop.
- Geometry comes from the terminal (resize the pane → the web surface follows).
- Input and focus go into that page.
- Launch is named and boring: pick the engine, get `BrowserReady`, keep going.

Protocol scaffolding is necessary. It is not sufficient. A helper that speaks
the right messages while the only visible UI is a floating Firefox chrome window
is **progress**, not parity.

## Four engines, four host stories

- **WebKit** — You host a real `WKWebView` (`NSView`). Closest to “put a view
  in a window.”
- **Chromium** — Content API / known fork patterns. Heavy, but **designed** to
  be hosted.
- **Ladybird** — LibWeb + their shell. Young; hard work, but **your**
  architecture.
- **Gecko** — No official desktop embed equivalent. You reverse-engineer
  **Firefox**.

WebKit wins the “easy” prize for a reason: the modern API _is_ a view. Input
often behaves like any other AppKit first responder. Compositing is “the view
is there.”

Chromium is a different kind of hard: giant tree, multi-process, custom
compositor bridges (on our stack, the CAContext / host-layer story). But
Chromium still has a **first-class content hosting** culture. You are not
pretending to be Chrome’s UI; you are attaching to an embedding surface people
expect to fork and ship.

Ladybird is hard because the engine is still growing—not because Mozilla (or
anyone) removed the front door.

Gecko is hard because **the front door moved**.

## The missing front door

For years people said “embed Gecko with libxul / XPCOM.” That was a real story
once. Product reality now is different:

- The modern, supported embed product is **GeckoView** — and it is
  **Android-only**.
- Desktop Firefox is optimized to be **Firefox**, not a content widget you drop
  into someone else’s process.
- Out-of-tree “call the old embedding exports and link” is a nostalgia path. We
  tried it. It **failed** as a practical route for our binary.

So the work becomes: live in the **Firefox tree**, boot enough of **XRE /
XPCOM**, and find whatever internal surfaces still create a browser context
(`nsIWindowlessBrowser` and friends), all without a vendor promise that those
hooks stay stable for third parties.

That is a research program with a build farm attached—not a weekend wrapper.

## Compositing is a second cliff

Even after you can load a URL, you still have to **show** it in a pane.

Chromium’s macOS story in our stack leans on a compositor path we already
understood: cross-process layers, hostable surface IDs, a known dance into the
terminal.

Gecko’s modern path is **WebRender → IOSurface-backed native layers**, with
cross-process handoff that is **not** “the same as Chromium’s CAContext
trick.” Headless mode makes this worse: Firefox’s headless path is happy to
**disable GPU compositing**, which is exactly what you do _not_ want if the
goal is a live pane, not a software screenshot.

Preferred long-term shape (from our architecture notes): something like an
**NSView overlay** or a **shared surface drawn into a Ghostboard-owned view**.
Neither is free. Both require owning the host surface, not just moving a
foreign window around with accessibility APIs.

## What we already proved

We did not only read source. We built Nightly, shipped an `ah-geckod` helper,
spoke the TermSurf protocol, and ran real loads.

Rough scoreboard:

1. **Full Firefox build** from a monorepo checkout — works (expensive, real).
2. **Process-windowless** load with TabReady / URL / title callbacks — works
   (in-tree).
3. **Ghostboard launch** with named `gecko` — works.
4. **Visible window + geometry follow** (process chrome aligned to the pane
   via platform geometry) — works as a **milestone**.
5. **Out-of-tree classic embedding init** — **fail**.
6. **True pane-hosted webview + real input/focus like the other engines** —
   **not done yet.** That is the open product work.

The milestone matters. It proves Gecko can live in our multi-engine world at
all. It also tempts a bad conclusion: “the window tracks the pane, ship it.”
That is how you quietly redefine “supported.”

A pane-**aligned** Firefox window is not a pane-**hosted** webview. Clip,
z-order, focus, and input all tell on you.

## Protocol complete ≠ product complete

Our protocol rule for engines is strict: every relevant message is either
implemented or **explicitly** unsupported—no silent ignores, no hangs.

Gecko can satisfy that rule while mouse and key still log “until embed.” That
is honest scaffolding. It is also a neon sign: the hard part is still the
**host surface and input path**, not another protobuf row.

If an engine only loads pages in a sidecar window and cannot take TermSurf
input, it is not “the same as WebKit in the terminal.” It is a demo of intent.

## Why we still want it

Strategic reason, not nostalgia: a multi-engine terminal that only runs
Chromium-family and WebKit is already powerful. Adding **Gecko** means the same
workbench can exercise the last major production browser lineage on the open
web—same session habits, different engine bugs, different layout, different
reality check.

Ladybird is the future-facing independent engine. Gecko is the production
Firefox lineage. Both belong in the set if the claim is “major engines,” not
“engines that were convenient to wrap.”

## What “done” has to mean next

We opened a follow-on bar that forbids the soft landing:

- Content is **hosted in or composited into** the terminal pane surface.
- Geometry is driven by TermSurf / the board—not only by chasing a foreign
  top-level window.
- Input and focus affect the page.
- Launch still looks like the other engines from the user’s point of view.

Process chrome can stay a temporary ladder rung. It cannot be the definition of
done.

## Closing

Gecko is the hard one because **embedding was never the product on desktop**,
the **compositor contract is foreign** to the Chromium path we already ship,
and **honest intermediate wins** (windowless load, named launch, a visible
window that follows the pane) look deceptively like finish lines.

WebKit gives you a view. Chromium gives you a hosting culture. Ladybird gives
you a tree you can still shape. Gecko gives you Firefox—and then the work of
making Firefox behave like a webview inside someone else’s window.

We are doing that work on purpose. The easy engines make the product real. The
hard engine makes the product complete.
]]></content:encoded>
            <author>Ryan X. Charles</author>
        </item>
        <item>
            <title><![CDATA[Folding the Portfolio into Astrohacker]]></title>
            <link>https://astrohacker.com/blog/2026-07-11-unifying-under-astrohacker</link>
            <guid isPermaLink="false">https://astrohacker.com/blog/2026-07-11-unifying-under-astrohacker</guid>
            <pubDate>Sat, 11 Jul 2026 18:00:00 GMT</pubDate>
            <description><![CDATA[We used to be a product mall. Terminal, Shell, Editor, and Web ship under Astrohacker today. Everything else is folding in—names still TBD.]]></description>
            <content:encoded><![CDATA[
We used to open [astrohacker.com](https://astrohacker.com) like a trade-show
booth map.

Seven tiles. Seven domains. TermSurf, Shannon, NuTorch, EarthBucks, KeyPears,
WebBuf, RSS Anyway—each with a formula line and a status badge. That was honest
about how the work got built. It was a terrible front door.

**We are folding the whole portfolio under the Astrohacker name.**

Not done. Underway. Some of it already ships as Astrohacker. Some of it still
wears the old labels while we merge code, packaging, and product surfaces.
Expect legacy sites to lag. The direction is set.

## What you can install today

This part is not aspirational. One Homebrew cask on Apple silicon macOS:

```bash
brew tap astrohackerlabs/astrohacker
brew trust astrohackerlabs/astrohacker
brew install --cask astrohacker
```

That ships:

- **Astrohacker Terminal** — multi-engine browsers (Chromium, WebKit, Ladybird)
  in the same window as your shell.
- **Astrohacker Shell** — ships with Terminal.
- **Astrohacker Editor** — ships with Terminal.
- **Astrohacker Web** — `ahweb`: open a real engine in a pane.

One brand. One download into `/Applications`. Pieces live under [docs](/docs),
not as four separate storefronts.

That is the first unification that matters: the **desktop workbench** is already
Astrohacker.

## What still gets folded in

The old grid was bigger than the workbench. Those projects are still company
work. Over time they get **Astrohacker + a second word** and land in the company
repos and release trains—not forever as peer consumer brands on the homepage.

Working names below are **aspirational**. **Final public names are TBD.** This
is not a launch checklist.

**Already folded or shipping under Astrohacker**

- **TermSurf** → **Astrohacker Terminal**. TermSurf stays the protocol name in
  code and history.
- **Shannon** → **Astrohacker Shell**. You will still see Shannon in lineage
  notes.

**Next (names drafts only)**

- **NuTorch** → Astrohacker Torch (TBD) — GPU tensors from the shell.
- **EarthBucks** → Astrohacker Cash (TBD) — electronic cash / EBX.
- **KeyPears** → Astrohacker Keys (TBD) — identity, secrets, encrypted
  messaging.
- **WebBuf** → Astrohacker Buf (TBD) — buffers and crypto libraries.
- **RSS Anyway** → Astrohacker Feed (TBD) — open-web feed aggregation.

Other experiments (Rickbait, and whatever we invent next) get the same rule when
they are ready: Astrohacker _something_, name TBD, merge when the product story
catches up.

## What “folded in” actually means

Not a logo sticker.

- **Brand** — users eventually meet Astrohacker first, not a maze of half-related
  domains.
- **Code and packaging** — projects move into company repositories and release
  trains where it makes sense.
- **Product surfaces** — Terminal is the desktop wedge. Wallet, keys, cash, and
  web services still point at the long-term **Astrohacker Economy** idea—agents
  and humans with identity and value under human control—without claiming those
  surfaces are fully renamed or shipped under new names today.

If keypears.com still says KeyPears tomorrow, that is expected. Cutover is
project by project.

## Why bother

A product grid flatters the builder. One company brand serves the user.

We build for people who live in the terminal and the browser—often with AI
coding agents in the loop. The workbench for that is Astrohacker Terminal. Money,
keys, libraries, and web tools belong under the same roof, not as seven competing
homepage cards.

## What to do

- **Use what ships:** install [Terminal](/), read the [docs](/docs).
- **Expect lag:** old domains and names stick around during the merge. Draft
  names above can change.
- **Follow along:** [blog](/blog), [Discord](https://discord.gg/S539YVq7sr),
  [GitHub](https://github.com/astrohackerlabs).

We are not saying the merge is finished. We are saying it has started—with a
Terminal that already works—and the rest of the portfolio is coming under
Astrohacker as we go.
]]></content:encoded>
            <author>Ryan X. Charles</author>
        </item>
        <item>
            <title><![CDATA[Building Software While You Sleep: The Fully Automated Software Development Lifecycle]]></title>
            <link>https://astrohacker.com/blog/2026-06-01-building-software-while-you-sleep</link>
            <guid isPermaLink="false">https://astrohacker.com/blog/2026-06-01-building-software-while-you-sleep</guid>
            <pubDate>Mon, 01 Jun 2026 12:00:00 GMT</pubDate>
            <description><![CDATA[Every tool in the Astrohacker portfolio is now built the same way: a goal is specified, one agent solves it, a second agent keeps it honest, and the loop runs end to end with no human in it.]]></description>
            <content:encoded><![CDATA[
We don't solve software issues at Astrohacker anymore. We specify them. The
issue gets a clear goal, explicit verification criteria, and a set of
guardrails — and then a command runs the rest. One agent designs experiments,
writes the code, and runs the tests. A second agent reviews its work
adversarially at every step. The loop runs end to end, and the software gets
built while we sleep.

This is not a demo or a roadmap. It is how the entire portfolio ships today —
the methodology Astrohacker founder [Ryan X.
Charles](https://ryanxcharles.com) developed across [TermSurf](https://termsurf.com),
[Shannon](https://shannonshell.com), [KeyPears](https://keypears.com), and
[EarthBucks](https://earthbucks.com), and now runs as a single automated
pipeline. We've crossed into the automated software development age, and the
commit logs are public.

## The lifecycle, end to end

Here is the whole loop, with no human in the middle of it.

A goal is written down — not a plan, a goal. What "solved" means is stated as
explicit verification criteria. The guardrails go next: which tests to write,
which linters and type checkers must pass, which code patterns the solution has
to follow. Then the machine takes over. It designs one experiment. A second
agent reviews that design. If the design passes, the first agent implements it,
runs the verification, and records the result. Then it designs the next
experiment, informed by what the last one taught it. The cycle repeats —
design, review, implement, verify, record — until the verification criteria
pass and the issue is closed.

That is the fully automated software development lifecycle. Specification in,
shipped software out, and the iteration in between belongs to the machine.

## The goal is the whole job

What's left for a human is the front of the loop, not the inside of it. The
work is writing the issue well enough that solving it becomes mechanical: a
clear description of the goal, concrete criteria for what counts as done, and
the guardrails that keep the solution honest. Once that is written down — in the
issue itself or in the project's `AGENTS.md` — the job is essentially over. We
are not the ones who solve the issue. We are the ones who define it precisely
enough that the solving can be automated. This is the front edge of a shift
the founder has called [setting the goal and walking
away](https://ryanxcharles.com/blog/2026-06-01-set-the-goal-walk-away).

## Experiments, not plans

The loop does not march through a plan. It runs experiments. Each experiment
either fully solves the issue, partially solves it, or fails — and failure is
fine, because a failed experiment is progress. It means something was poorly
understood, and now it isn't. Every result is logged whether it passes or
fails, so the record narrows toward the goal with each iteration. The
documentation is the primary artifact; the code is what happens when an
experiment returns a pass.

This is [research-driven
development](https://ryanxcharles.com/blog/2026-03-08-research-driven-development),
and it is the substrate the automation runs on. You never list the experiments
up front, because the result of experiment N is what tells you what experiment
N+1 should be. The lab notebook stays current without effort because the same
agents that write the code write the notebook — which is exactly what makes the
notebook cheap enough to keep, and what makes automating the loop possible at
all.

## Adversarial review is the keystone

The thing that makes an unattended loop trustworthy is a second agent trying to
tear the work apart. It is not enough for an agent to write and pass its own
tests — marking your own homework is how slop ships. So a separate agent
performs an adversarial review at the two stages that matter: the experiment
_design_ must pass before any code is written, and the _result_ must pass before
the next experiment begins.

The reviewer doesn't need to be a different model. It needs to come at the work
cold — a fresh context, not a fork. A clean built-in subagent works; so does a
call out to a separate CLI tool. Different context is all you need, as long as
both agents are state-of-the-art. That cold second look is what keeps an
overnight run from drifting, and it is the difference between an automated
pipeline you can trust and one you have to babysit.

## The receipts

The claim is falsifiable, and the proof is in the repos. With this flow we
added full PDF support to TermSurf — a GPU-accelerated Chromium browser inside
the terminal — in about a day; rendering PDFs through a Chromium embedder by
hand would have cost months. PDFs now render inline, scroll, select, and print.
And as this post goes out, the loop is doing something no one would attempt by
hand: porting Ghostty from Zig into Rust, one terminal subsystem at a time. That
issue is over a hundred experiments deep, nearly all passing, with hundreds of
commits landed in a matter of days — tabstops, page storage, selection,
formatters, escape-sequence handlers — each one designed, reviewed, implemented,
tested, and reviewed again, with no hands on the keyboard. Click into the
`issues/` folder of any Astrohacker repo and you are reading the actual
engineering history, not a sanitized summary.

## Why now

This works today because three things converged at once. The models finally
crossed the quality bar where their code is better than what most engineers
write by hand. The tooling grew goal-level orchestration, so a whole issue can
be handed off in a single command. And the best practices — tests, explicit
verification, adversarial review — matured into a loop that produces output you
can actually trust. None of these alone is enough. Together they mean the
software development lifecycle, end to end, can run without a human inside it.

So that's how Astrohacker builds now. Set the goal. Hack the universe.
]]></content:encoded>
            <author>Ryan X. Charles</author>
        </item>
        <item>
            <title><![CDATA[The EarthBucks 2.0 Network Plan]]></title>
            <link>https://astrohacker.com/blog/2026-05-18-earthbucks-2-network-plan</link>
            <guid isPermaLink="false">https://astrohacker.com/blog/2026-05-18-earthbucks-2-network-plan</guid>
            <pubDate>Mon, 18 May 2026 12:00:00 GMT</pubDate>
            <description><![CDATA[EarthBucks 2.0 separates mines from pools, launches with three production mines, supports SPV wallets, and opens the path to new proof-of-work applications.]]></description>
            <content:encoded><![CDATA[
EarthBucks 2.0 is becoming a working system.

The last update was about progress: Rust mines, database state, transaction
validation, Merkle ordering, mine-to-mine networking, mining-pool substrate, and
the start of the new EarthBucks app.

A wallet opens and checks `mine1.earthbucks.com` for headers and proofs.

A browser miner logs into `earthbucks.com`, gets work from the pool, and submits
shares without talking directly to a mine.

A website embeds Compucha, asks a visitor for proof-of-work instead of a
captcha, and that work can eventually point at the same EarthBucks mine network.

That is the split EarthBucks 2.0 is building toward: **mines settle, pools
coordinate work, wallets hold money, and apps create demand.**

The old model put too much into one place. The new model gives each part a job.

## The first mine network

EarthBucks 2.0 will launch with at least three production mines:

- `mine1.earthbucks.com`
- `mine2.earthbucks.com`
- `mine3.earthbucks.com`

Those names are not decoration. In EarthBucks, mines are identified by domain
names. A mine is a professional network participant: it validates transactions,
maintains UTXO state, synchronizes transaction order with peer mines, accepts
solved work, and participates in finality.

This is different from Bitcoin's anonymous public node model. EarthBucks mines
are known services with domain identities. At launch, the first mines will be
operated by Astrohacker. In the future, mines may live at other domains and may
be operated by other businesses.

Three known mines are enough to stop pretending the network is a single server.

## Mines are not pools

The most important product change in EarthBucks 2.0 is that mines and pools are
separate concepts.

In the early EarthBucks design, a mine was basically what Bitcoin would call a
mining pool. The same service handled users, miners, validation, accounting, and
network behavior.

That was useful for getting EarthBucks 1.0 shipped. It is not the right shape
for EarthBucks 2.0.

In EBX2, a **mine** is a validating network service. It owns consensus-facing
behavior. It does not need to be a public consumer app.

A **pool** coordinates proof-of-work. It asks mines for work templates,
distributes work to miners, tracks shares, and submits solved work back to the
mine that issued it.

The mine is the settlement layer. The pool is the economic coordinator for
hashpower.

Those should not be the same thing.

## earthbucks.com remains the first pool

`earthbucks.com` will continue to be the main EarthBucks app.

It will also continue to be the first EarthBucks mining pool.

Internally, the new app is currently called `www-pool`. That is an engineering
name, not the public product name. The old `www-earthbucks-com` app needs to
keep running while the new app is built, so the new project needs a different
directory and package name.

The public destination is still EarthBucks.

The new app will eventually live at `earthbucks.com`. During development, it may
be useful to run it somewhere else, but the product boundary is clear:

- `earthbucks.com` is the wallet, pool, docs, and status app.
- the mine subdomains are validating network services.

The app is not a mine.

That distinction matters because it lets more pools exist later without making
every pool a consensus participant.

## Wallets connect with SPV

Users should not need to run mines.

EarthBucks wallets should be able to connect to mines with SPV-style
verification. A wallet can submit transactions, verify headers and Merkle
proofs, inspect transaction status, and show finality without becoming part of
the validating mine network.

The EarthBucks app will include a wallet. That is the default user experience.

But EarthBucks 2.0 should also support third-party wallets. If someone wants to
build a different wallet UI, a mobile wallet, a terminal wallet, or a wallet
inside another product, they should be able to connect to the mines and verify
what they need to verify.

The user-facing app and the network should not be welded together.

That is the point of having mines, pools, and wallets as separate roles.

## More pools are coming

At launch, the first pool is `earthbucks.com`.

In the future, there should be more pools.

The most likely second pool is Compucha.

Compucha is a proof-of-work captcha replacement. Instead of asking users to
click traffic lights, decipher distorted text, or train someone else's image
classifier for free, a website can ask the user to perform a small amount of
proof-of-work.

The current Compucha direction is already useful: an embeddable iframe, a
challenge endpoint, a verification endpoint, WebGPU mining when available, and a
WASM fallback when it is not.

The EarthBucks direction makes it better.

If proof-of-work is needed to log into a website, that work should not merely
vanish. It should be able to mine EarthBucks. The user proves they spent real
computation, the website gets a better abuse filter than a captcha, and the work
can participate in an actual cash network.

Proof-of-work is better than captchas.

Earning money is better than proof-of-work that goes nowhere.

That is why pools should be separate from mines. `compucha.com` can become a
pool with a totally different product surface from `earthbucks.com`, while still
talking to the same EarthBucks mine network.

## KeyPears is the protocol layer

EarthBucks 2.0 is also being built in the same direction as KeyPears.

KeyPears is the identity, messaging, and secret-exchange layer of the
Astrohacker portfolio. It uses domain-based federation, cryptographic
authentication, and proof-of-work where appropriate.

EarthBucks needs the same style of internet-native plumbing.

The plan is for EarthBucks services to use KeyPears-compatible protocol ideas so
users and apps can send authenticated messages, transaction data, and service
requests across compatible domains.

That matters because EarthBucks is not just one website. It is a network:

- mines at domain names;
- pools at domain names;
- wallets that connect to mines;
- apps that create reasons to earn and spend EBX;
- services that need to exchange signed messages and transactions.

KeyPears gives that world a common protocol direction.

## What users can expect

EarthBucks 2.0 is not live yet, and some implementation details will keep
changing as the system hardens.

But the direction is no longer fuzzy.

The first production network has multiple mines. Wallets connect to mines
without becoming mines. The EarthBucks wallet ships in the app, and third-party
wallets should be able to use the same network.

Pools become a product layer. `earthbucks.com` is first. Compucha is the next
serious candidate: a proof-of-work captcha replacement that can turn login
friction into useful mining.

KeyPears-compatible service communication ties the pieces together so the
Astrohacker projects do not become isolated islands.

And continuity still matters. EarthBucks 2.0 is not a new genesis block, not a
balance reset, and not a new coin. It is the next network architecture for
EarthBucks.

## The simple model

Mines settle.

Pools coordinate work.

Wallets hold money.

Apps create demand.

That is the EarthBucks 2.0 network plan.

Build the mines. Connect the pool. Open the wallet. Let other apps plug in.

Hack the universe.
]]></content:encoded>
            <author>Ryan X. Charles</author>
        </item>
        <item>
            <title><![CDATA[Astrohacker Begins EarthBucks 2.0]]></title>
            <link>https://astrohacker.com/blog/2026-05-04-astrohacker-begins-earthbucks-2-0</link>
            <guid isPermaLink="false">https://astrohacker.com/blog/2026-05-04-astrohacker-begins-earthbucks-2-0</guid>
            <pubDate>Mon, 04 May 2026 12:00:00 GMT</pubDate>
            <description><![CDATA[EarthBucks 2.0 has begun: Rust mines, peer-to-peer consensus, Bitcoin Cash liquidity, and self-custodial EBX/BCH swaps.]]></description>
            <content:encoded><![CDATA[
Astrohacker has begun work on [EarthBucks 2.0](https://earthbucks.com/blog/2026-05-03-beginning-work-on-earthbucks-2-0).

This is not a new coin. It is not a new genesis block. It is not a balance reset. It is the next major engineering phase for EarthBucks: the phase that turns the current single-mine system into a real peer-to-peer mine network, connects EBX to Bitcoin Cash, and gives users a self-custodial path to trade between them.

EarthBucks is the money layer of the Astrohacker portfolio. TermSurf is about the interface. KeyPears is about identity, secrets, and messaging. EarthBucks is about electronic cash.

The cash part now gets serious.

## What 2.0 means

EarthBucks 2.0 has three practical goals:

1. Build the peer-to-peer mine network.
2. Add a Bitcoin Cash wallet.
3. Enable atomic swaps between EBX and BCH.

The mine network is the foundation. In EarthBucks, mines are not anonymous hobby nodes. They are accountable services at domain names. They validate transactions, maintain chain state, build blocks, synchronize with other mines, and form the settlement layer of the system.

The first 2.0 mines will be operated by Astrohacker. That is the right starting point. The goal is not to pretend the network is decentralized before the software exists. The goal is to make the system correct, observable, operational, and useful, then expand from there.

Bitcoin Cash is the liquidity path. BCH is already electronic cash with users, wallets, exchanges, and a market price. If EBX can be swapped with BCH without a centralized custodian, EBX gets a real path to price discovery.

That is the thesis: build the real network, connect it to liquid cash, and let EBX find a market.

## What has started

The first work is not a new screen. It is consensus code.

Over the past few days, the EarthBucks 2.0 work has moved through a long sequence of implementation issues. The core direction is now clear: server-side mines should be built on a Rust consensus library, with byte-for-byte parity against the existing TypeScript implementation where the current chain behavior matters.

That work now covers the substrate mines need:

- keys, addresses, public key hashes, and signatures;
- Blake3 hashing and deterministic ECDSAb3 signing;
- serialization primitives, VarInts, and 256-bit target numbers;
- headers, target calculation, and canonical difficulty-adjustment math;
- transactions, scripts, standard templates, and mint transaction shapes;
- the script interpreter;
- transaction verification;
- Merkle trees, Merkle proofs, blocks, and ID wrappers;
- mint transaction validation and block acceptance;
- Pow5 header work validation.

This is the part of a cryptocurrency that cannot be approximate. A mine cannot "mostly" parse a header. A transaction verifier cannot "kind of" agree with the wallet. Difficulty math cannot depend on whatever two floating-point implementations happen to do this week. Work validation cannot accept a header because the shape looks plausible.

Consensus software is boring until it fails. Then it is the whole product.

## Why this belongs at Astrohacker

Astrohacker exists to make the projects reinforce each other.

EarthBucks is not an isolated blockchain experiment. It belongs next to the rest of the portfolio:

- [TermSurf](https://termsurf.com) is a better interface for people who live in terminals.
- [Shannon](https://shannonshell.com) is a shell built for real command-line work.
- [KeyPears](https://keypears.com) is identity, messaging, and secrets under user control.
- EarthBucks is money for that world.

The connection is not "crypto" as a category. The connection is infrastructure. Keys, addresses, signatures, feeds, shells, browsers, messages, payments. The portfolio is a set of tools for people and software that need to act on the internet without asking permission from five unrelated platforms.

EarthBucks 2.0 is how the money piece grows up.

## What 2.0 is not

EarthBucks 2.0 is not a disruption to existing users. The 1.0 chain history is preserved. Existing balances, keys, and addresses must continue to work.

It is also not a post-quantum rewrite. EarthBucks already has practical quantum-resistance properties from its public-key-hash design, key non-reuse, and fast settlement model. Post-quantum cryptography matters, but forcing immature large-key primitives into 2.0 would be the wrong trade.

It is not the release for every advanced feature. Tokens, broader smart contracts, a new proof-of-work function, unlimited script usage, and third-party mine operation can all wait. They may matter later. They are not the next bottleneck.

The next bottleneck is the real network.

## What comes next

The next phase is still engineering, not theater.

The remaining work includes the 2.0 mine database schema, inter-mine synchronization, the first Astrohacker-operated mine deployment, the Bitcoin Cash wallet, the atomic swap protocol, and the exchange interface.

Some details will change. The first mine domains may change. Storage choices may change. The swap design needs its own careful work. That is normal. The direction is settled.

EarthBucks 2.0 means Rust mines, domain-based peer-to-peer consensus, Bitcoin Cash liquidity, and self-custodial EBX/BCH swaps.

Astrohacker builds the products. EarthBucks moves the money.

Hack the universe.
]]></content:encoded>
            <author>Ryan X. Charles</author>
        </item>
        <item>
            <title><![CDATA[KeyPears Goes Hybrid Post-Quantum]]></title>
            <link>https://astrohacker.com/blog/2026-04-27-keypears-hybrid-post-quantum</link>
            <guid isPermaLink="false">https://astrohacker.com/blog/2026-04-27-keypears-hybrid-post-quantum</guid>
            <pubDate>Mon, 27 Apr 2026 12:00:00 GMT</pubDate>
            <description><![CDATA[Every KeyPears message and signature now combines classical and post-quantum cryptography by default.]]></description>
            <content:encoded><![CDATA[
[KeyPears](https://keypears.com) is now hybrid post-quantum. Every message, every signature, every account — by default, on the only code path.

This is not a feature flag. It is not an enterprise tier. It is not a compatibility mode for cautious users. The protocol's cryptographic spine has moved, and the safe path is now the normal path.

## What "hybrid" means here

| Purpose          | Classical      | Post-quantum | Construction            |
| ---------------- | -------------- | ------------ | ----------------------- |
| Signatures       | Ed25519        | ML-DSA-65    | Both required           |
| Key agreement    | X25519         | ML-KEM-768   | Shared secrets combined |
| Symmetric crypto | AES-256-GCM    | —            | Unchanged               |
| Hash & KDF       | SHA-256 family | —            | Unchanged               |

Each message is encrypted with a key derived from _both_ an X25519 Diffie-Hellman exchange and an ML-KEM-768 encapsulation, combined through HKDF. Each message is signed with _both_ an Ed25519 signature and an ML-DSA-65 signature over the same canonical envelope. Recovering plaintext or forging a signature requires defeating both halves.

## Why hybrid, not pure post-quantum

ML-KEM and ML-DSA are NIST-standard and have been through years of public analysis. But they don't have the multi-decade deployment history of elliptic curves. New cryptography is _new_.

Hybrid hedges in both directions:

- If a fault-tolerant quantum computer breaks elliptic curves, the post-quantum half still protects you.
- If a serious flaw is found in the post-quantum algorithms, the classical half still protects you.
- If both hold up, the construction is stronger than either alone.

This is the conservative call, not the exciting one. The goal is not novelty. The goal is defensibility.

## What changed for users

Mostly nothing visible. You still have a `name@domain` address. You still sign in. You still send messages and store secrets in the vault. Federation still works through `.well-known/keypears.json`.

Under the hood each account now holds four private keys instead of one — Ed25519, X25519, ML-DSA-65, ML-KEM-768 — all client-side encrypted under a key derived from your password. The server still sees only ciphertext.

The tradeoff is size: post-quantum keys and signatures are larger than their elliptic-curve counterparts. KeyPears moves messages, credentials, and notes — not video — so the extra kilobytes are a good trade.

## Why this is an Astrohacker move

One of the through-lines of the [Astrohacker portfolio](/blog/2026-04-13-introducing-astrohacker) is that **cryptography is plumbing, not a product category**. EarthBucks is the same idea applied to money; KeyPears applies it to identity, secrets, and messaging.

Hybrid post-quantum on the default path is what "plumbing" actually looks like. Not a checkbox, not a tier, not a "secure mode" — just the baseline. The user doesn't choose it because the user shouldn't have to.

The baseline should keep moving up. This is one step.

## What it doesn't fix

It doesn't make a compromised device safe. It doesn't add forward secrecy to stored messages — KeyPears keeps ciphertext around so users can recover history across devices, which is a deliberate simplicity tradeoff. It doesn't make implementation bugs impossible.

For the full protocol description, the construction details, and the parts that didn't fit here, read the [KeyPears post on this change](https://keypears.com/blog/2026-04-26-keypears-is-hybrid-post-quantum) and the [whitepaper](https://keypears.com/whitepaper.pdf).

Hack the universe.
]]></content:encoded>
            <author>Ryan X. Charles</author>
        </item>
        <item>
            <title><![CDATA[Introducing RSS Anyway]]></title>
            <link>https://astrohacker.com/blog/2026-04-24-introducing-rss-anyway</link>
            <guid isPermaLink="false">https://astrohacker.com/blog/2026-04-24-introducing-rss-anyway</guid>
            <pubDate>Fri, 24 Apr 2026 12:00:00 GMT</pubDate>
            <description><![CDATA[A feed aggregator that starts with the open web — and lets you add anything else.]]></description>
            <content:encoded><![CDATA[
The open web still publishes. People are still writing blogs, shipping
changelogs, pushing releases, posting essays, uploading videos, dropping papers
on arxiv. The shortage isn't content. The shortage is a good way to read it.

RSS Anyway is an attempt at that good way. It's a feed aggregator that discovers
blogs automatically, generates feeds for sites that don't have them, and now
lets you add anything else you want to follow.

It's in alpha, live at [rssanyway.com](https://rssanyway.com).

## What it is

RSS Anyway reads [Hacker News](https://news.ycombinator.com) as a signal layer,
classifies every URL it sees, and either finds a native RSS/Atom/JSON feed or
generates one by scraping. The result is a hot-ranked homepage of the latest
posts from across the open web — a lot of sites you already know, and a lot you
don't. Built on Bun, TanStack Start, and MySQL.

## Three things that make it different

### It generates feeds for sites that don't have them

A lot of the open web doesn't expose RSS at all. RSS Anyway's classifier handles
GitHub repos, YouTube channels, Discourse forums, arxiv authors, and generic
static blogs — walking paths, scanning links, extracting sitemaps, reading index
pages. If a site publishes on any kind of schedule, we'll usually find a way to
turn it into a feed. Each feed is also re-exported as RSS, Atom, and JSON, so
you can read it in any client.

### Follow anything, literally

New this week: sign in, hit the `+` button in the bottom-right, paste any URL.
If we can classify it, you see a preview of the feed and a **Follow** button. If
we can't, we'll tell you exactly why. Either way, the feed joins the aggregator
for everyone — the index is user-extensible by design.

### Sign in with KeyPears

No passwords, no OAuth, no signup flow. Type your KeyPears address — something
like `you@example.com` — sign once with your key, and you're in. Use the public
[keypears.com](https://keypears.com) node or host your own. RSS Anyway discovers
your node via `.well-known`, verifies the signature, and creates your account on
the spot. Federated identity, cryptographically checked, zero friction.

## What you can do right now

- **Browse hot (`/`) and new (`/new`)** — Reddit-style ranking over the entire
  index, or reverse-chronological if you just want the firehose.
- **Follow feeds or whole domains** — hover any domain, click follow. Your
  subscriptions show up at `/following`.
- **Submit any URL at `/submit`** — if it's classifiable, it's indexed in
  seconds.
- **Browse by domain** at `/domains/[domain]` — see every feed we've found for a
  site, and every recent item.

## Why this exists

The big algorithmic feeds optimize for engagement with their own network. RSS
Anyway optimizes for access to the open web. The bet is that a decent aggregator
of everything-that-publishes is more valuable in the long run than a great
curator of a walled garden. And the bet is that giving people a way to _add
their own sources_ — instead of asking them to trust a team of editors — is how
you get there.

It's alpha. The classifier will get some sites wrong. The hot ranking will
sometimes hot the wrong stuff. The sign-in flow assumes you know what KeyPears
is. All of that will get better.

In the meantime: go sign in, follow a few domains, submit your favorite blog.
Tell us what we got wrong.

[rssanyway.com](https://rssanyway.com).

Hack the universe.
]]></content:encoded>
            <author>Ryan X. Charles</author>
        </item>
        <item>
            <title><![CDATA[Introducing Astrohacker]]></title>
            <link>https://astrohacker.com/blog/2026-04-13-introducing-astrohacker</link>
            <guid isPermaLink="false">https://astrohacker.com/blog/2026-04-13-introducing-astrohacker</guid>
            <pubDate>Mon, 13 Apr 2026 12:00:00 GMT</pubDate>
            <description><![CDATA[One umbrella for a portfolio of tools spanning shells, cash, messaging, and the absurd.]]></description>
            <content:encoded><![CDATA[
For years I've been shipping projects under scattered banners — a blockchain here, a shell there, an encrypted messenger, a social-network joke that got out of hand. Each one had its own domain, its own repo, its own half-written about page. None of them had a home.

**Astrohacker is that home.** It's the umbrella company for everything I build: a single brand for a portfolio of tools that all share one premise — that science and technology are how we explore and understand the universe, and that the best way to explore is to build.

This post introduces the portfolio.

## The portfolio

### [TermSurf](https://termsurf.com) — `TERMINAL + BROWSER`

A protocol that embeds GPU-accelerated web browsers directly in your terminal. Type `web` and you're browsing in your shell. No window-switching, no context loss, no leaving the keyboard. Currently in alpha. → [termsurf.com](https://termsurf.com)

### [Shannon](https://shannonshell.com) — `NUSHELL + BASH`

A shell built on nushell with seamless bash compatibility. Press Shift+Tab to switch modes: structured data pipelines on one side, decades of muscle memory on the other, environment and working directory synced between them. Shannon is not AI-first and doesn't try to be — it's a real shell for real work. In beta. → [shannonshell.com](https://shannonshell.com)

### [EarthBucks](https://earthbucks.com) — `ELECTRONIC CASH`

A global electronic cash system. GPU-mined, instant finality, email-like addresses, 42 million EBX. A from-scratch blockchain built on the original Bitcoin premise — peer-to-peer electronic cash — adapted for an era where AIs are going to need to pay each other. Shipped 1.0. → [earthbucks.com](https://earthbucks.com)

### [Rickbait](https://rickbait.com) — `FRONT PAGE`

An AI-powered clickbait generator, algorithmic feed, and advertising auction market. It is exactly as serious as it sounds, and exactly as serious as the rest of the web. Alpha. → [rickbait.com](https://rickbait.com)

### [KeyPears](https://keypears.com) — `SECRET EXCHANGE`

Federated encrypted messaging, a secret manager, and an authentication provider, in one project. The pitch is that your keys, your secrets, and your identity should live in one place you control — not scattered across five SaaS dashboards. Alpha. → [keypears.com](https://keypears.com)

## The through-lines

Looking at the portfolio as a whole, a few themes surface:

- **The shell is the interface.** TermSurf, Shannon, and most of the development tooling I reach for live at the command line. The terminal is not a legacy interface — it's the most powerful UI we have, and it deserves better infrastructure.
- **Cryptography is plumbing, not a product category.** EarthBucks and KeyPears both treat crypto as a primitive for solving a concrete problem — moving money, holding secrets — rather than as an end in itself.
- **Play is allowed.** Rickbait is a joke, and it's also a real product with a real auction market. The jokes inform the serious work and vice versa.

## What's next

Astrohacker is a founder-led portfolio company, and 2026 is the year the portfolio starts pulling its weight commercially. Expect shipping cadence to pick up on all fronts, expect a few new projects to join the roster, and expect this blog to track it all.

If you want to follow along, this blog has [RSS](/blog/feed.rss.xml), [Atom](/blog/feed.atom.xml), and [JSON](/blog/feed.json) feeds. Pick your poison.

Hack the universe.
]]></content:encoded>
            <author>Ryan X. Charles</author>
        </item>
    </channel>
</rss>