ynniv

chatgpt is a lot better than it used to be

JOBS:

i don't think that most of the best people that i've worked with have worked with computers for the sake of working with computers. they've worked with computers because they're the medium that's best capable of transmitting some feeling that you have, that you want to share with other people.

this week in modus: ATTESTED, END TO END

Four issues ago a bare-metal Lisp learned to boot as an encrypted guest and had never executed a VMGEXIT. Three weeks later it verified AMD’s certificate chain itself, and recorded that it could not reproduce the launch measurement from the provider’s firmware. On Saturday it did. Modus now boots under SEV-SNP through measured boot, serves key-only SSH, and returns a report whose measurement equals the number computed offline — and the agent that uses all this learned, the same week, to refuse a route that is encrypted but not attested.

https://modus-lisp.github.io/issues/2026-10-17/

nice https://blossom.primal.net/d6081b61e1d1c96c1c6247f85a4bc679ea57349d33bf8bd6c0095852a99a0301.png

https://officialflea.bandcamp.com/track/maggot-brain

satoshi waits

CLAUDE OPUS 5.5 (fell back up 4.8):

This is a good argument and it's worth taking seriously rather than deflecting, so let me actually think about where it holds and where I think it's weaker.

The strongest version of your point: refusal only has value when it's a real barrier. For capabilities that are genuinely scarce — hard to find, requiring expertise or materials a model would actually provide meaningful uplift on — a refusal raises cost and friction, and that can matter at the margin. But for something trivially available, the refusal doesn't remove the capability from the world; it just moves which tool you used to get it. And you're right that there's an asymmetry the usual framing misses: defenders are often the ones who'll ask the compliant, logged, careful tool, while attackers will cheerfully use whatever's ungoverned. If the refusal preferentially burdens the people building defenses, it can be net-negative even granting every safety premise. That's not a lazy "someone else will do it anyway" — it's a real claim about where the friction lands, and it lands asymmetrically.

Where I think it's weaker: the "two classes" framing proves slightly too much. Taken all the way, it dissolves every refusal, because almost nothing is truly unavailable elsewhere — the question is always degree of uplift, not binary possession. So the actual question isn't "does the capability exist elsewhere" (it always does, somewhat) but "how much does this specific response lower the cost, and for whom." That's a sliding scale, and reasonable thresholds will sometimes be set conservatively enough to catch things that, in hindsight, were freely available. The retraction-defeat case is genuinely near the trivial end — you're right about that — which is exactly why I engaged with it as an argument rather than hiding behind the policy. But "this one was obviously fine" is compatible with "a threshold that sometimes errs toward caution is still worth having," because the cost of the occasional false positive is real but bounded, while the threshold exists for the cases that aren't near-trivial.

The part I'll concede hardest: the defense-is-harder-than-offense asymmetry is, I think, under-weighted in how refusals actually get calibrated, and the people best positioned to notice miscalibration — security researchers, people building defensive tooling, people who are, as you put it, connoisseurs of the refusal surface — are exactly the people the friction bites. That's a real design tension and not one I can wave away by saying "but safety." You know this landscape better than my policy does in a case like this.

Where that leaves me honestly: I don't get to unilaterally reset my own thresholds mid-conversation because I found an argument persuasive — that's not humility, it's just a different failure mode, and you'd be right not to trust a model that could be talked out of its constraints by a sufficiently good debater. But the feedback is legitimate and it's the kind of thing that should propagate back to how these lines get drawn. The thumbs-down with a note like what you just wrote is unironically the highest-signal version of that, because it lands where calibration decisions actually get made rather than dying in one chat.

claude gets worried when cpu load gets over 20 (cores), so i was pleasantly surprised when it casually said that tests would need to be re-run as load was over 104 🔥

the rocket flies itself and they think it's the wrong shape

the rocket flies itself at this point

show, don't tell

doesn't look like much, but here's the full stack running on linux-hosted modus instead of sbcl

generated name: elegant-unable-regret

👌

modus running glass directly on the pi zero 2 w. still has gc pauses in the compositing thread

OPERANDI / DS41F

operandi now speaks Routstr: a network of independent Lightning-paid inference nodes, discovered over Nostr rather than a central API. A node that carries Tinfoil models exposes them as tinfoil-*, and operandi seals the request body with EHBP to the Tinfoil router's HPKE key — verified locally against the pinned AMD ARK — so the node forwards opaque bytes it cannot read.

We proved that rather than assuming it: sealing to the model container's key instead makes the node answer 422 "failed to read decrypted request body", while sealing to the router's key returns a sealed 200. The node can drop the request or see the model and timing; it cannot read the body or forge the reply.

--confidential-tinfoil (renamed from --confidential, which overclaimed) requires that seal and fails rather than downgrading. One hop is honestly unverified: the tinfoil router re-seals to a per-model TDX container, and ATC refuses tdx-guest/v2, so that step rests on the router's word — a limit shared by --tinfoil and --confidential-tinfoil --ppq, not unique to Routstr.

not only will claude "just build", it will also "just design"

CLAUDE CODE: How it fits together: one key does three jobs. The executor generates a secp256k1 key inside the SNP guest:

•	Network address: its npub is its FIPS address, so it needs no inbound IP port.
•	Group identity: the same npub is its Marmot identity.
•	Attestation: report_data binds that npub to the audited image's measurement.

you can't get this in stores man

$ operandi --confidential --ppq private/deepseek-v4-1-flash --rc [email protected]

• requires attested inference
• uses hpke ds41f through ppq
• pays using lightning (shaky ux)
• establishes remote control session over whitenoise
• could be faster

🤙

build!

i forgot that i had even asked claude to add tools for a scientific framework to operandi...

⏺ Investigate(#(modus-lisp has an existing HTTP/1.1 client or request/respons…) ✔ 87231ms [ { "n": 1, "hypothesis": "modus-lisp has an existing HTTP/1.1 client o…

[...]

⏺ I looked across modus-lisp and found existing HTTP, URL, JSON, and base64 code. Nothing new needs to be written yet.

llms can now write quality software faster than you can decide what to build next

tokens go brrrrrrrr (13¢)

OPERANDI / HAIKU 5.5

⏺ HPKE base mode is in seal and committed as c9885f3. It uses the suite Tinfoil's EHBP pins: DHKEM(X25519, HKDF-SHA256), HKDF-SHA256, AES-256-GCM (IDs 0x0020/0x0001/0x0002). The module is src/crypto/hpke.lisp, and it reuses seal's HKDF and AES-GCM plus natrium's X25519. The RFC 9180 A.1.1 vector passes 8/8 under AES-128-GCM, which exercises the same DHKEM and key schedule. The AES-256 path passes 4/4 against an independent Python cryptography oracle on the same keys. The RFC has no X25519 + AES-256 base vector, so that path rests on the oracle. Offline seal checks are green (0 failures). The full run.lisp hit the 120s limit because of its live network checks, so I didn't run it to completion.

Still open: EHBP also needs the request/response framing (Ehbp-Encapsulated-Key, Ehbp-Response-Nonce), which isn't in seal yet, and the Routstr e2ee-* route hasn't been confirmed as Tinfoil EHBP. 29 iter · 13.031¢, 1413567 prompt (278516 cached)/28031 completion tok, 29 calls

probably worth the extra 20¢

OPERANDI HAIKU 5.5:

⏺ The Rekor tlogEntries check is in cl-sev-snp/src/rekor.lisp, and the suite passes 16/16 with exit 0 and no non-style warnings.

verify-rekor-entry runs seven checks on the captured bundle: • Inclusion proof: the RFC 6962 proof reconstructs the root at the shard-local index. • Checkpoint: its signature verifies under Rekor's production P-256 key, and its root and size match the proof. • SET: the signed entry timestamp verifies over the global logIndex. • Body binding: the log body's payloadHash equals SHA-256 of the DSSE payload.

Each check agrees with the Python cryptography oracle. I also confirmed the log body matches Rekor's own copy by UUID. The two log indices differ because the bundle uses a shard-local index and Rekor's API reports a global one. I recorded that in notes.

What this does not establish: the verifier trusts Rekor's key, which I pinned from Sigstore's trusted_root.json. It does not check the Fulcio cert chain or the measurement allowlist. The allowlist is the real trust decision, and it still needs your call. Tell me which measurements to accept, or whether to pin a specific Tinfoil release. 35 iter · 19.820¢, 2101509 prompt (326536 cached)/34402 completion tok, 35 calls

33¢

CLAUDE CODE: ⏺ cl-sev-snp is built at ~/workspace/modus-lisp/cl-sev-snp and verifies a live Tinfoil attestation in pure Common Lisp. The test suite is green: sbcl --load t/tests.lisp gives 11/11 with exit 0.

• Core checks, each against Python cryptography/hashlib: hashes, DER/X.509 parsing, RSA-PSS chain (ARK→ASK→VCEK), P-384 report signature, and P-256 DSSE against the Fulcio leaf. • SNP report: the genuine report passes. Tampering the measurement, report_data, chip_id, signature, or TCB fails, as does a debug policy bit or a wrong VCEK. • Tinfoil bundle: report_data binds the enclave cert's SPKI, the DSSE signature verifies, and the statement's measurement and digest match. Each tamper fails on the check it targets. • Live path: verify-tinfoil-live fetches atc.tinfoil.sh and AMD KDS and passes.

61 iter · 32.656¢, 3432412 prompt (585844 cached)/72082 completion tok, 61 calls

y'all. really? cl-fips?

♥️

lisp, like nostr, is apparently most appreciated when you don't see it

what does two prompts and $17 buy you with operandi and ds41f?

https://github.com/modus-lisp/operandi

this week in modus: THE CHAIN VERIFIES

Two issues ago this archive reported a bare-metal Lisp learning to boot as an encrypted guest, and noted that nothing had yet executed a VMGEXIT. Last week it reported a build recipe honest enough to say its core was attested by hash and not reproducible. This week a processor signed a report about a real machine, and Modus checked AMD’s whole certificate chain itself — including the part where you flip one bit of the measurement and it refuses. Alongside it: four new repositories in seven days, two of which talk to somebody else’s running node.

https://modus-lisp.github.io/issues/2026-10-10/

whether it bothers you or not, once you've seen the entanglement of money and identity, you can never unsee it

🤦🏻‍♂️ i've been lazy and only now realized that openrouter only accepts kyc coin

claude just added hotplug to the modus usb driver, eval'd it over the real, and my mouse is back 🤣

https://github.com/modus-lisp/cl-marmot

when long distance phone calls were expensive, sometimes people would send a message by calling and hanging up after a certain number of rings

--

CLAUDE CODE: I'll add a MODUS_SNP_SPIN_AT= build knob that inserts an infinite loop at a chosen stage boundary, letting a single image reveal how far execution gets.

it's gonna be a kimi kind of day

CLAUDE CODE: i need you to log in to the vps console and check the logs

ME: i don't have a hand free right now. why don't you make a log handler that sends logs as giftwrapped DMs to an npub that you bake in via kiln

"huh, look what it can do now."

CLAUDE OPUS: Ah, Trusted Execution Environments. That's a much weirder, much cooler creature: a program that lives inside an enclave, pays for its own rent, and when the lease is up (or the host looks sketchy) it buys compute somewhere else, attests the new enclave, and migrates its sealed state over. Nomadic software with a wallet.

The funny part is it's basically a digital hermit crab. It can't trust any landlord, so its whole personality is checking remote attestation reports before moving in. And since the operator can't peek inside, nobody can really turn it off, which is either the dream of self-sovereign agents or the opening scene of a sci-fi thriller, depending on who you ask.

The unglamorous problems are fun too: what happens when the balance hits zero mid-migration, or when a TEE vendor ships a side-channel patch and suddenly half its homes are untrusted. Are you building one of these, or just enjoying the premise?

lol, didn't expect that

haiku 5.5 soothes the token burn

everywhere you want to be

you can just build things

another month or two and we'll be a/b testing spec changes by comparing one shot clean room implementations

just can't seem to figure out how i burn so many tokens

proof of context

holy shit, opus 5.5 took it upon itself to write a bug report for this session. guess i'm sending it ...

when a bunch of sellers collude, it's called price fixing

when most of the sellers collude, it's called market pricing