Suppose Alice wants to share an AI-generated security review with Bob. Bob wants to know that the review is exactly what a particular agent produced for a particular input.

In other words, Bob wants evidence that

output = Agent(input)

for a specific agent, model version, configuration, and input, without running the same inputs, and spending tokens and time.

Today, there is no standard way to prove this.

The simplest solution is to rely on a trusted authority.

An inference service—or an independent auditor—runs the agent and signs the result.

The certificate could contain:

Agent: OpenAI Code Security Review
Model: GPT-5.5
Agent version: v3
Input hash: SHA256(...)
Output hash: SHA256(...)
Timestamp: ...
Signature: ...

This does not prove that the model executed correctly. It proves that the trusted authority attests that it produced this output for this input.

For many applications, that is already enough. It is no different from trusting a software publisher's code signature or a Certificate Authority on the web.

AI providers, code hosting platforms, or independent auditors could all publish signed attestations for AI-generated artifacts.

A stronger goal is to remove the trusted authority entirely.

Instead of relying on a signature, the inference itself would produce a cryptographic proof that the output is exactly the result of evaluating the specified model on the specified input.

Verification would no longer depend on trusting the service that performed the inference. Anyone could verify the proof independently.

This is an active area of research. Zero-knowledge proofs, zkVMs, and other verifiable computation techniques are making progress, but generating proofs for frontier AI models remains expensive.

Verifiable inference would make AI outputs much more useful: IF you trust an AI agent to do a job, then verifiable inference will allow us to do it once and reuse the reuslt.

A code review could be accompanied by proof that it was generated by a specific review agent. A legal analysis could be verified to have come from a particular model version. Researchers could cite AI-generated analyses with confidence that readers are seeing the original output.

Further reading

• EZKL — An open-source toolkit for generating zero-knowledge proofs of machine learning inference. One of the most mature implementations of verifiable ML today. https://github.com/zkonduit/ezkl oai_citation:0‡GitHub

• ZKML: An Optimizing System for ML Inference in Zero-Knowledge Proofs (EuroSys 2024) — One of the first papers to demonstrate zero-knowledge proofs for non-trivial machine learning models. oai_citation:1‡DOI

• A Survey of Zero-Knowledge Proof Based Verifiable Machine Learning — A comprehensive overview of the field, including verifiable inference, training, current systems, and open challenges. oai_citation:2‡arXiv

• Verifiable ML Model Inference (ERC-7992 Draft) — A proposed Ethereum standard for identifying ML models and verifying cryptographic proofs of inference. Interesting as an example of how verifiable inference could become interoperable. oai_citation:3‡Ethereum Improvement Proposals

Unless it’s a really established project, with many eyes on it, it’s a leap of faith. How do I know what the code actually does?

In theory, I could review it. But let’s be realistic, no one is fluent enough in every programming language, and no one has the time to carefully review the code of every tool they want to try; at least not me.

README is a claim

Every decent repo has a README, and the README file is a claim. The code is the fact.

A tool that says "renames files based on EXIF data" has no business making network calls, reading ~/.ssh, or spawning subprocesses. If it does, you don't need threat modeling or a CVE database. You've found it. Most malicious code reveals itself exactly at the point where behavior exceeds stated purpose.

So the question becomes: does the capability stay inside the claimed scope? A tool claiming LAN-only sync should have no HTTP client and no hardcoded external hosts. A tool claiming "offline, no telemetry" should have zero outbound capability, full stop. The narrower the claim, the sharper the check — and a violated narrow claim is the strongest finding you can get.

This is the kind of task LLM agents happen to be good at. They're patient, they read every file, and they don't get bored on line 400. Grep the dependency manifest, check every network call, decode every base64 blob, read every if that branches on the current date. It's mechanical.

The audit-repo skill

So I wrote a skill that does exactly this. It's structured around the README-vs-code principle rather than a generic checklist:

1. Establish the claim. Confirm the repo is the one you meant (not a typosquat), record the exact commit hash, and write down in one sentence what the project says it does — including any scope limits it declares for itself ("offline", "LAN-only", "read-only").
2. Read the code against that claim. Network activity, filesystem access outside the working directory, environment scraping, dynamic execution, persistence (cron, systemd, .zshrc, LaunchAgents), obfuscation, self-downloading payloads. Then the ones a grep alone misses: credential-store access, clipboard and screen capture, environment fingerprinting, time-gated behavior, covert exfiltration through a channel that looks legitimate, unsafe deserialization, insecure randomness for secrets, hardcoded backdoor conditionals.
3. Check the dependencies. Typosquats, wide-open version ranges, git-URL deps, and above all install-time scripts — postinstall runs before any other part of your review matters.
4. Sandbox anyway. A clean read is not a guarantee.

It also records positive findings: stripping setuid bits from received files, redacting secrets by default, atomic writes. Deliberate defensive choices tell you something about the author.

The output is a short prose report — findings, verdict, and a reliability note kept separate from the malice verdict, because a tool can be perfectly honest and still eat your files.

Finally, a report card: a color-coded label, one row per category, styled after the privacy nutrition labels on app stores, except each row is graded against the stated claim rather than scored in isolation. Green means "matches the claim or absent". Red means "undisclosed, or contradicts the claim". You can read it in three seconds.

Get the code-security-review skill from github.com/vrypan/skills. Install it and next time, before you install a cool new tool, ask your AI agent "perform a security review of https://...".

We shouldn’t do it, but, let’s admit it, we all do it, especially when we feel safe, on a computer entirely under our control.

export OPENAI_API_KEY=sk-...
curl -H "Authorization: Bearer ghp_..." https://api.example.com
psql postgres://alice:password@example.com/db

But it’s not just shell history. It may be a SELECT statement in your ~/.mysql_history, or a quick test stored permanently in your ~/.python_history, and so on.

And recently, AI coding assistants have introduced one more secret-concentration point. Claude Code, Codex, Gemini CLI, and Copilot CLI keep full session transcripts on disk; transcripts that may contain secrets copied from .env files, terminal output, or configuration files.

User: Connect to the production database.

Tool output:
DATABASE_URL=postgres://alice:password@example.com/db
OPENAI_API_KEY=sk-...
AWS_SECRET_ACCESS_KEY=...

shg scans these locations for credentials, and anything that looks like an API key or an access token. It scans shell and REPL histories, environment variables, AI agent command histories, and AI agent session transcripts. Everything runs locally, there is no network access or telemetry, and findings are redacted by default.

For example, running shg scan reports secrets found in shell/REPL history files or environment variables:

$ shg scan

[!!!] export OPENAI_API_KEY=s*************...**************5
      ~/.zsh_history:148 [inline_assign]

[!!!] curl -H "Authorization: Bearer g*************...**************5...
      ~/.zsh_history:576 [auth_header]

2 finding(s) detected (2 high, 0 medium, 0 low).
Remove flagged history entries and rotate affected credentials.

shg deep scans AI agent transcripts and groups findings by session instead of by line:

$ shg deep

~/.claude/projects/myapp/3f2c….jsonl
  [!!!] known_token   ghp_****…****2345   (3×, tool_output)
        …export GITHUB_TOKEN=ghp_****…****2345…

1 secret(s) across 1 session file(s).
Rotate each credential, delete the affected session files, and make sure
this directory is not synced, committed, or world-readable.

If you are using zsh there is also a way to run shg on every command before it’s stored in history and prevent it from landing there if it contains secrets.

# the command executes normally, but it's not saved to history

$ export GH_TOKEN=ghp_381289xj_82j7nk_23
[shg] Warning: possible secret detected — not saved to history.

shg can’t eliminate the risk of secret leaks. But it makes it easier to discover accidental exposure before history files or agent transcripts are backed up, synchronized, committed, or shared.

shg is currently on v0.2.6 and has been significantly improved since the last time I wrote about it.

Most of the public opposition to CSAR boils down to "no surveillance" as a first principle, full stop. On the other side, there are at least some documented cases where the existing, voluntary Chat Control 1.0 has helped catch people committing crimes against children — which is usually where the counter-argument lands: "yes, but we will save the kids". Both of these are too short to be useful.

Here are my notes, and a huge list of references for further investigation.

Scanning private communications without consent becomes legal

EU law is clear that scanning private communications is illegal without consent.⁶

CSAR practically changes this, by permitting "voluntary" scanning of content.⁷

• before: scanning was prohibited unless covered by a (temporary) exception.³
• after: scanning becomes an ordinary, permanent legal possibility under EU law.

On-device scanning is the only technically viable option

What does scanning mean?

A chat app may scan the content (your texts, photos, videos) either on-device, in transit (as the message is transmitted) or in storage (when the message is stored in their servers).

Modern apps apply cryptography to encrypt these messages, and the strongest model is end-to-end encryption (E2EE). This means that the message is encrypted before leaving your device and it can only be decrypted on the device of the recipient. If properly implemented, it is computationally infeasible to decrypt the message without the keys stored in the recipient's device.

The initial version of CSAR did not exempt end-to-end encrypted services from detection obligations.⁹ In practice, complying would mean weakening encryption — for example, by adding backdoors — so that messages could be decrypted without the sender's or recipient's consent. This approach introduces many problems, including the possibility of a security leak that would jeopardize the security of every user's communications to criminals and foreign adversaries.

The Commission repeatedly stated that it was not banning end-to-end encryption. At the same time, depending on the final text, providers may be required — or permitted — to detect known CSAM (Child Sexual Abuse Material), unknown CSAM, and grooming.

Which leaves providers with only one option: scan all content, on-device, before it is encrypted.

Millions of false positives

So, your phone, or your laptop, will have to scan content you send and receive to identify CSAM.

Scanning can be classified under two categories:

• Match a content hash (a digital fingerprint) against a database of known CSAM hashes.
• Try to use machine learning and fuzzy algorithms to identify unknown CSAM.

The first one is a mature and very low-error method. The second one is much more prone to errors.

But here is where big numbers are important. Even 0.1% false positives, across billions of daily messages, produces enormous volumes of flagged innocent content — and every flag is a person suspected of one of the worst crimes that exist.¹⁰

That photo you sent to your doctor in a moment of despair, when the rash on your kid's belly looked extremely alarming? It could flag you in some database as a potential child offender.

Not to mention consensual sexting between teenagers. How would you feel if your 17-year-old, who is texting and exchanging photos with their partner, was accused of CSAM or grooming? In order to "protect" our kids, we may be actually harming them.

Keep in mind that wrongful suspicion is not the only consequence in these cases: flagging may lead to house searches and police database entries.¹¹

CSAM scanning is an attack vector

On-device models and hash databases can be extracted and reverse-engineered.¹³

Perceptual hashes admit adversarial collisions — i.e. innocent-looking images crafted to match database hashes. This isn't hypothetical. Shortly after Apple announced NeuralHash in 2021, researchers demonstrated practical hash collisions.¹⁴

This is a new attack vector: an adversary can send victims content that appears innocuous but will trigger reporting. People already harass journalists by sending them CSAM and then reporting them to the authorities. Automated reporting might provide a means to scale up such attacks.

Now, add to this that flagged users are not notified, cannot contest the classification, and may enter police databases as CSAM suspects on automated evidence — with downstream effects on employment vetting, custody, border crossings.⁹

The remedy for false positives is even worse

OK, you may say, we will put guardrails, to protect innocent citizens from being wrongfully accused. We can't entirely depend on automated systems, we will also have humans review these flags.

CSAR has this covered: flagged content may be reviewed by provider staff, by the EU Centre, and by law enforcement.⁹

Purpose creep: once the infra is in place, it can be used for any type of content

Once the technical ability, the legal framework and the legal procedures for client-side scanning against a centrally distributed database exist, extending it to other content categories is a political decision, not a technical project.¹⁵

Child sexual abuse is something everyone agrees on, so it's always the first step of such frameworks. But it is important to understand CSAR is not just a law. It is also a technical framework and infrastructure that makes flagging additional types of content just a database update.

The next target could be something more controversial, like immigration. Then maybe something even more controversial like copyrighted material. Then a vague definition of misinformation. Then some type of dangerous political speech.

You may say that most or all of these things are already covered by existing laws. But these laws have processes and visibility, cases have to be brought to justice, and they can be challenged, and the prosecuting authorities have to pick where they spend their time and resources; which is a welcome limitation that makes the system work better.

CSAR is automated enforcement: no friction, zero cost to scale. You can't sue 1,000,000 EU citizens in one afternoon, but you can easily flag them under the suspicion that they sent illegal material.

The blocklist is secret and unauditable

And, what is in the blocklist, anyway?

Ordinary users cannot inspect the hash lists the EU Centre would distribute, and independent public auditability is inherently limited — reviewing the source material (CSAM) used to build it is itself illegal.

So, we have a scanning system that we can't review what it is scanning for, and even curation errors (not to mention intentional abuse) propagate silently to every device in Europe.

If you think shadow banning in social media is bad, think about a centralized blocklist, blessed by EU Regulation, that you can't review, and which — for some weird reason — is blocking your content.

Exporting the risk outside the EU

While EU citizens may accept that they can trust their local legal framework, messaging is global. Protocols and clients are shared.

If EU compliance weakens clients or protocols, it degrades the security of at least everyone who communicates with EU users, including journalists, dissidents, and abuse victims outside the EU whose threat models are far worse.

It also exposes EU users when they communicate with users outside the EU to these threat models too, since other jurisdictions may flag other types of content.

The small-provider / fediverse problem

CSAR's core obligations — risk assessment, mitigation, reporting, exposure to detection orders — apply to hosting and communication services of any size. There is no exemption for small providers, unlike other EU digital laws.¹⁷

What does a risk assessment mean for a single-admin Mastodon or Matrix homeserver? What about a decentralized, open source project? Who serves a detection order on software with no company behind it?

This leads to compliance costs only Big Tech can absorb and further centralization of communications onto the platforms whose scanning produced the justifying dataset.

Is it even worth it?

Client-side scanning in mainstream apps is trivially defeated by motivated users: pre-encryption, custom clients, self-hosted servers, non-compliant platforms.

Even assuming a perfect classifier, the users reliably covered are practically the ones who aren't hiding anything.

Further reading (secondary)

• EDRi, "Is this the most criticised draft EU law of all time?": https://edri.org/our-work/most-criticised-eu-law-of-all-time/
• EDRi CSA Regulation document pool (the best running index of primary documents, incl. the Ombudsman maladministration findings and the LIBE–Johansson–Thorn correspondence): https://edri.org/our-work/csa-regulation-document-pool/
• Balkan Insight, "'Who Benefits?' Inside the EU's Fight over Scanning for Child Sex Content" (25 Sept 2023): https://balkaninsight.com/2023/09/25/who-benefits-inside-the-eus-fight-over-scanning-for-child-sex-content/
• Balkan Insight, "Europol Sought Unlimited Data Access in Online Child Sexual Abuse Regulation" (29 Sept 2023): https://balkaninsight.com/2023/09/29/europol-sought-unlimited-data-access-in-online-child-sexual-abuse-regulation/
• Balkan Insight, "Europol 'Revising' Conflict of Interest Screening After BIRN Investigation" (11 Oct 2024): https://balkaninsight.com/2024/10/11/europol-revising-conflict-of-interest-screening-after-birn-investigation/bi/ The related European Ombudsman decision (case 2091/2023/AML, 21 Feb 2025) found maladministration in how Europol handled the moves of two former staff members to Thorn: https://www.ombudsman.europa.eu/en/decision/en/200017 Two further maladministration findings concern the Commission (DG HOME): the refusal to disclose its expert-group composition (https://www.ombudsman.europa.eu/en/decision/en/176658) and the refusal to disclose documents about Thorn's lobbying (https://www.ombudsman.europa.eu/en/news-document/en/189565).
• NCMEC CyberTipline data: https://www.missingkids.org/gethelpnow/cybertipline/cybertiplinedata and 2025 first look: https://www.missingkids.org/blog/2026/the-work-never-stops-first-look-at-ncmecs-2025-data
• IWF annual reports: https://www.iwf.org.uk

But many times, you just want to share a thought or an idea, or some code.

In the past, the only way for most of us was to hunt for images under Creative Commons licenses. Writting a post about the history of CR? Try to find an old typewritter photo that you like, and is compatible with your blog, and blends nicely with your content.

A couple of years ago, we got a new tool: AI-generated images. Just tell an AI what you want, itterate a couple of times, and done.

But AI-generated images in blog posts are no longer cool. Everyone does it. And with the exception when an image is a really good fit, it looks like a 2000 PowerPoint using animated transitions and WordArt.

I think the ideal solution is a card generated by your post title and abstract, the date, the tags, your blog name, etc. In other words, present your blog post the way you would like it to be presented, not how the third party service decides to format your title or trim your text.

There are many tools that generate images like this, but most of them use node.js and I dread the moment I run npm install which pulls 1,000 dependencies.

So I wrote my own tool, og-img in Rust (thank you, Claude). A single binary, that does exactly waht I want, and it's quite fast (though I have not done any serious optimizations yet).

Just install

brew tap vrypan/tap
brew install og-img

and run

og render \
  --icon vrypan.png \
  --site blog.vrypan.net \
  --title "AI-generated blog post images are not cool any more" \
  --text "but OpenGraph empeds still look much better when there is one." \
  --tags en,blogging,howto \
  --date "July 10, 2026" \
  --theme github-dark \
  -o og.png

This was fun: A "Where Is Waldo" game for QR codes.

Can you find it? Your phone can!

The basic idea

QR scanners don't see color. The first thing a decoder does is convert the image to grayscale — collapsing each pixel to a single brightness value via roughly 0.299·R + 0.587·G + 0.114·B — then binarize and hunt for the finder patterns (the three corner squares) and module grid. Everything downstream operates on luminance alone.

That gap is the whole trick: luminance carries the code; hue and saturation are free to do whatever you want. You have two perceptual channels the scanner is blind to, and humans hunting for a pattern rely heavily on exactly those channels.

So the code is rendered as a luminance difference — "dark" modules low-luma, "light" modules high-luma — but each module is painted a vivid random color at its assigned brightness. The key subtlety is that a fully saturated color's true luminance depends on its hue: pure blue sits around 0.11, pure red around 0.30, pure yellow near 0.89. So "dark" modules don't have to be dark and muddy — you can use electric blues, reds, and violets that are naturally low-luminance at full saturation, and reserve the bright hues (yellow, cyan, green) for "light" modules.

To the hyman eye it's a saturated confetti, but converted to grayscale it's a scannable QR.

The code

#! /usr/bin/env python

import cv2
import numpy as np
PAYLOAD = "https://blog.vrypan.net/2026/07/07/where-is-qrdo/"
MOD = 8
GRID_W, GRID_H = 192, 96
N_DECOYS = 180
enc = cv2.QRCodeEncoder.create()
qr = enc.encode(PAYLOAD)[2:-2, 2:-2]
n = qr.shape[0]
det = cv2.QRCodeDetector()
LUMA = np.array([0.114, 0.587, 0.299])   # BGR
# --- curated DARK palette (BGR), all low-luma, balanced across families ----
# reds need V<255 to stay low-luma; blues/violets are low-luma at full V.
DARK = np.array([
    [0,   0,   220],   # strong red
    [0,   0,   180],   # deep red
    [30,  0,   200],   # red-magenta
    [255, 0,   0],     # pure blue
    [200, 0,   0],     # deep blue
    [255, 40,  0],     # blue-cyan lean
    [200, 0,   120],   # indigo
    [180, 0,   180],   # violet
    [140, 0,   200],   # purple-red
], np.float32)
# --- LIGHT palette (BGR), all high-luma, vivid + bright ---
LIGHT = np.array([
    [0,   255, 255],   # yellow
    [0,   255, 150],   # yellow-green
    [0,   255, 0],     # green
    [255, 255, 0],     # cyan
    [255, 255, 150],   # pale cyan
    [150, 255, 255],   # pale yellow
    [200, 255, 200],   # mint
], np.float32)
print("dark palette lumas:", np.round(DARK @ LUMA / 255, 2))
print("light palette lumas:", np.round(LIGHT @ LUMA / 255, 2))
def build(seed):
    r = np.random.default_rng(seed)
    # --- random QR placement (keep a 1-module margin for the finder halos) ---
    qx = int(r.integers(1, GRID_W - n))
    qy = int(r.integers(1, GRID_H - n))
    is_dark = r.random((GRID_H, GRID_W)) < 0.40
    for cx, cy in [(qx, qy), (qx+n-7, qy), (qx, qy+n-7)]:
        is_dark[cy-1:cy+8, cx-1:cx+8] = False
    for y in range(n):
        for x in range(n):
            is_dark[qy+y, qx+x] = qr[y, x] < 128
    for _ in range(N_DECOYS):
        dx = int(r.integers(1, GRID_W-9)); dy = int(r.integers(1, GRID_H-9))
        if (qx-10 < dx < qx+n+1) and (qy-10 < dy < qy+n+1):
            continue
        s = int(r.integers(6, 9))
        is_dark[dy:dy+s, dx:dx+s] = True
        is_dark[dy+1:dy+s-1, dx+1:dx+s-1] = False
        inner = int(r.integers(1, 3))
        is_dark[dy+2:dy+s-2-(inner-1), dx+2:dx+s-2-(inner-1)] = True
    canvas = np.zeros((GRID_H, GRID_W, 3), np.float32)
    di = r.integers(0, len(DARK), (GRID_H, GRID_W))
    li = r.integers(0, len(LIGHT), (GRID_H, GRID_W))
    for y in range(GRID_H):
        for x in range(GRID_W):
            canvas[y, x] = DARK[di[y, x]] if is_dark[y, x] else LIGHT[li[y, x]]
    img = cv2.resize(canvas.astype(np.uint8), (GRID_W*MOD, GRID_H*MOD),
                     interpolation=cv2.INTER_NEAREST)
    return img, (qx, qy)
import secrets
# random search order (fresh OS entropy each run) so the QR lands in a
# different spot every time, rather than always picking the first seed that works
seeds = list(range(1, 4000))
np.random.default_rng(secrets.randbits(64)).shuffle(seeds)
for seed in seeds:
    img, (qx, qy) = build(seed)
    if det.detectAndDecode(img)[0] == PAYLOAD:
        cv2.imwrite("qr_redblue.png", img)
        print(f"seed {seed}: decodes OK -> qr_redblue.png  (QR at module {qx},{qy})")
        break
else:
    raise SystemExit("no working seed found")

Update 08-07-2026

Variation: Instead of scattering decoy finder-lookalike squares at random, place them on a regular lattice and align the QR so its three real finder patterns land on lattice nodes. Now the real corners are just three nodes in a field of near-identical squares and the easy to find "three squares in an L" tell disappears.

#! /usr/bin/env python

import cv2
import numpy as np
import secrets

PAYLOAD = "https://blog.vrypan.net"
MOD = 8
GRID_W, GRID_H = 288, 144
PITCH = None          # set to n-7 after QR is encoded; = finder spacing
JITTER = 2            # decoys wander +/- this many modules off their node
CLEARANCE = 6         # lattice leaves this margin around the QR body

enc = cv2.QRCodeEncoder.create()
qr = enc.encode(PAYLOAD)[2:-2, 2:-2]
n = qr.shape[0]
PITCH = n - 7         # so QR finders at (0,0),(n-7,0),(0,n-7) fall on nodes
det = cv2.QRCodeDetector()
LUMA = np.array([0.114, 0.587, 0.299])   # BGR

DARK = np.array([
    [0,   0,   220],   # strong red
    [0,   0,   180],   # deep red
    [30,  0,   200],   # red-magenta
    [255, 0,   0],     # pure blue
    [200, 0,   0],     # deep blue
    [255, 40,  0],     # blue-cyan lean
    [200, 0,   120],   # indigo
    [180, 0,   180],   # violet
    [140, 0,   200],   # purple-red
], np.float32)
LIGHT = np.array([
    [0,   255, 255],   # yellow
    [0,   255, 150],   # yellow-green
    [0,   255, 0],     # green
    [255, 255, 0],     # cyan
    [255, 255, 150],   # pale cyan
    [150, 255, 255],   # pale yellow
    [200, 255, 200],   # mint
], np.float32)
print("dark palette lumas:", np.round(DARK @ LUMA / 255, 2))
print("light palette lumas:", np.round(LIGHT @ LUMA / 255, 2))

def draw_decoy(is_dark, x, y, size, center):
    """Concentric square with a deliberately wrong ratio (scanner rejects it)."""
    if x < 1 or y < 1 or x+size >= GRID_W or y+size >= GRID_H:
        return
    is_dark[y:y+size, x:x+size] = True
    is_dark[y+1:y+size-1, x+1:x+size-1] = False
    c0 = (size - center) // 2
    is_dark[y+c0:y+c0+center, x+c0:x+c0+center] = True

def build(seed):
    r = np.random.default_rng(seed)
    is_dark = r.random((GRID_H, GRID_W)) < 0.40
    # place QR origin on a lattice node (random node -> random placement)
    nx = (GRID_W - n) // PITCH
    ny = (GRID_H - n) // PITCH
    qx = int(r.integers(0, nx)) * PITCH + 2
    qy = int(r.integers(0, ny)) * PITCH + 2
    # jittered-lattice decoys, skipping the QR's own footprint
    x0, y0, x1, y1 = qx-CLEARANCE, qy-CLEARANCE, qx+n+CLEARANCE, qy+n+CLEARANCE
    for j in range(0, GRID_H, PITCH):
        for i in range(0, GRID_W, PITCH):
            if x0 <= i <= x1 and y0 <= j <= y1:
                continue                      # inside QR area: leave for real finders
            jx = i + int(r.integers(-JITTER, JITTER+1))
            jy = j + int(r.integers(-JITTER, JITTER+1))
            size = int(r.choice([6, 8]))      # wrong sizes -> wrong ratio
            center = int(r.choice([2, 4]))
            draw_decoy(is_dark, jx, jy, size, center)
    # real finder halos + stamp the QR (overwrites lattice at its 3 nodes)
    for cx, cy in [(qx, qy), (qx+n-7, qy), (qx, qy+n-7)]:
        is_dark[cy-1:cy+8, cx-1:cx+8] = False
    for y in range(n):
        for x in range(n):
            is_dark[qy+y, qx+x] = qr[y, x] < 128
    # paint colours
    canvas = np.zeros((GRID_H, GRID_W, 3), np.float32)
    di = r.integers(0, len(DARK), (GRID_H, GRID_W))
    li = r.integers(0, len(LIGHT), (GRID_H, GRID_W))
    for y in range(GRID_H):
        for x in range(GRID_W):
            canvas[y, x] = DARK[di[y, x]] if is_dark[y, x] else LIGHT[li[y, x]]
    img = cv2.resize(canvas.astype(np.uint8), (GRID_W*MOD, GRID_H*MOD),
                     interpolation=cv2.INTER_NEAREST)
    return img, (qx, qy)

# randomized search order -> different working seed (and placement) each run
seeds = list(range(1, 8000))
np.random.default_rng(secrets.randbits(64)).shuffle(seeds)
for seed in seeds:
    img, (qx, qy) = build(seed)
    if det.detectAndDecode(img)[0] == PAYLOAD:
        cv2.imwrite("qr_lattice.png", img)
        print(f"seed {seed}: decodes OK -> qr_lattice.png  (QR at module {qx},{qy})")
        break
else:
    raise SystemExit("no working seed found -- raise the seed ceiling or lower density")

It was about the sport.

A game that unites people, not in some kumbaya way, but through passion, and tears of joy and disappointment.

Football is life. A great baller can also be a shitty character at the same time. An average player can become a hero. A careless moment can have irreversible consequences. Talent gets recognized regardless of origin. Human error is recognized as part of the game.

There's only one thing that all football fans hate: outside interference.

It was about America in 2026

For most of the world, America in 2026 is a symbol of corruption, arrogance, and disrespect. It wasn't always like this. Many of us grew up looking up to America as a symbol of opportunity, and freedom, and openness.

Not any more.

It wouldn't have been the same if a small team from Africa had somehow lobbied to bend the rules. But this was not a random team, from a small country, with a prime minister the rest of us had never heard of.

It was the USA, probably the most powerful country in the world, and Trump, who has trash-talked every single nation and leader around the world. And he made a call to the clown who is President of FIFA, asking for the rules to be bent in his favor, and got his way.

It was also the arrogance of Americans who may have had zero affinity with the sport, explaining to us how the game works, how the rules work, why "everyone would have done the same if they could".

Like a Greek tragedy

And, after all this, after the feeling of injustice, after the frustration of being talked down by arrogant people, eventually, The Beautiful Game restored world order.

USA-BEL 1-4.

But it's nice for a blog to provide feedback mechanisms. I see it when I read something on my RSS reader, and I want to like, or leave a short comment to let the author know I appreciate what they wrote, or give them feedback on the topic they cover.

Enter listnr.

listnr is a ActivityPub "bridge":

• it maintains a Fediverse identity (an ActivityPub actor that anyone on Mastodon can follow), like @blog@vrypan.net
• it watches my RSS feed and publishes new posts as they appear
• it provides a simple API that a small js widget can use to show likes, boosts and comments under each post.

It is built as a single executable (written in Go) and for a blog with moderate traffic, it can be hosted on a very small VPS ¹.

Why ActivityPub and not ATProto, or Farcaster or something else?

I want self-sovereignty. I don't want to depend on any external resource or service². ATProto requires me to depend on third-party relays. A Farcaster node on the other hand, requires a VPS that will cost much more³, and my RPi5/16GB at home probably couldn't handle the task.

Using ActivityPub was the only solution I could trivially self-host at home, or on a VPS for a very small amount —something I would be ok paying for even during periods I don't post much.

I’ll keep exploring options, and I may expand listnr to support more protocols if it makes sense, but for now this is the only direction that gives me self-sovereignty I can afford.

Yes, it's AI-coded, if you have some deep, ideological objection, don't bother; I like my AI-coding tools, and I couldn't have built this in two days without them.

Help me test by commenting/liking/sharing on Fediverse. Link bellow.

One hundred years ago, on September 26, 1929, President Herbert Hoover gathered a group of social scientists at the White House. He asked them to begin research on the most detailed report ever produced on the state of the nation. Four years later, running more than 1,500 pages long, Recent Social Trends was published, offering an unusually granular look at life in the mid-1920s.

America, 1926: What a Forgotten 100-Year-Old Report Says About Who We Are

I'll cherry-pick, for my own archive.

[...] No other country rivaled America’s automotive love affair. According to the historian Bill Bryson, 1920s Kansas alone had more vehicles than France. Car ownership created an entirely new way of thinking about the self in relation to the environment—an “automobile psychology.” Social scientists spoke of the modern “gypsy family,” which seemed to spend more time inside the car than outside it.

Something that still strikes Europeans when they visit US. Americans, and America, has a special relationship with cars. Dreams, habits, infrastructure, cities, almost every aspect of the american life has the car at its core.

It is remarkable to read the report’s analysis of radio’s effect on American life, because it reads so alarmingly modern. Above all, the authors were concerned that radio encroached on individuality by mind-wiring each American to a global monolith of news and entertainment. Mass media organizations created “greater possibilities for social manipulation,” they wrote, and radio threatened to turn the individual into what the philosopher Martin Heidegger in this period called a “they-self”—a being who, failing to achieve authenticity, fully adopts the tastes, habits, and beliefs of the universal crowd.

But the social scientists did not see these trends as altogether good. They worried that modern life, defined in equal parts by urbanization and technology, obliterated people’s values and their sense of self. Even as they gawked at the increase in patents—which grew more than 20-fold between the 1850s and the 1920s—they worried that a growing number of discoveries would bring “problems of morals, of education, of law, of leisure time, of unemployment, of speed, of uniformity and of differentiation.”

[...] In 1903, the sociologist Georg Simmel anticipated the anxieties of the Twenties—ours and theirs—when he observed that in cities “money takes the place of all the manifoldness of things” and becomes “a common denominator of all values.” Money “hollows out the core of things, their peculiarities, their specific values, and their uniqueness and incomparability in a way which is beyond repair.”

Go read the whole piece: https://www.derekthompson.org/p/america-1926-an-absurdly-deep-dive

People increasingly use them as the interface to the world's knowledge. They write software, learn, conduct research, communicate, and solve problems through them. As they become general-purpose infrastructure, they should increasingly be treated like other infrastructure.

The closest historical analogy is the telephone network.

Telephone companies made enormous upfront investments to build nationwide networks. Society allowed them to recover those investments and earn profits by charging for access. It did not allow them to decide who could make lawful phone calls or what services could be built on top of the network. They became common carriers: providers of a neutral service.

Commercial LLMs should evolve in the same direction

AI providers should be free to charge whatever the market will bear for inference. They should compete on model quality, latency, reliability, and price. But once a customer pays for inference, the resulting outputs should be theirs to use for any lawful purpose.

That includes model distillation.

Blocking distillation is analogous to an incumbent telephone company claiming the right to prevent customers from using its network to build competing communications services. Common carrier law evolved in the opposite direction: the operator could charge for access, but not dictate what lawful services customers built on top of the network.

The same principle should apply to LLMs. The provider is selling computation, not control over what customers lawfully do with its results.

Making distillation a protected right would likely increase token prices in the short term. AI companies would need to price inference closer to its true cost, because selling below cost would no longer subsidize only customer acquisition—it would also subsidize future competitors.

That's how competitive markets should work. Anyone building a competing model would also pay those same market prices to distill existing models.

Competition would shift from contractual restrictions to engineering: better models, lower costs, and more efficient infrastructure.

The natural way to give back

This is also consistent with how frontier models came to exist. They were trained on humanity's accumulated knowledge: scientific research, literature, open-source software, and countless public contributions spanning centuries. The engineering required to build these systems deserves to be rewarded. The reward should be payment for providing inference, not the power to control how customers use the outputs they have purchased.

As LLMs become essential infrastructure, neutrality should become part of the bargain. Society provides the knowledge these models are built on; society should retain the right to build on them.

I’ve probably missed some, the discussion was really long, and I’ve also received feedback though other channels. I will post again if I feel there’s more to share on the topic.

Favoring the incumbents

A point I missed the first time.

In the EU design, an authority issues me an attestation that I'm of legal age; it lands in my digital wallet. When a site needs to check, the wallet generates a zero-knowledge proof that it holds the attestation, without disclosing it.

With most wallets, we assume the user protects their credential — nobody voluntarily leaks the password to a wallet holding money for example. Age verification inverts this: the user is part of the threat model. Some users, given the chance, will happily share their "over 18" attestation with a minor.

So the system can't trust the user. It has to trust the device or the wallet instead. And for the issuer to know the attestation stays locked inside, it has to control which devices (modern iOS/Android) and which wallets (those carrying a government-signed certificate) are allowed.

The bottom line, and it's not a bright one:

• In practice, let’s admit it, you'll have to use iOS or Android.
• Probably the official government wallet.
• Experimental mobile OSes are locked out of any site requiring age verification.
• Alternative OSes could qualify, but only by getting EU-certified — which often defeats the point of running one.

The silver lining: your desktop can be anything. Run a hand-compiled Linux distro on obscure hardware with a browser you built yourself — you'll just scan a QR code with your phone when age verification comes up.

How much this shifts the balance is a judgment call. For me it's a mark against the proposal, but not a fatal one.

Can I trust the official app?

The EU open-sourced the wallet. But how do I know the binary my government actually shipped matches that source — that it doesn't quietly log which sites requested verification, or hand those URLs to an intelligence agency?

The EU must address this, and not just for these wallets, but for every piece of software that becomes European digital infrastructure. I'd strongly support a directive mandating reproducible builds and signed source/build metadata. It's the only way citizens can actually trust the stack.

Standards fragmentation

Also valid. The EU has one age-verification standard, the UK another, California a third. What's a site supposed to implement? I don't have an answer.

What's built to "protect the kids" gets used on everyone later

Today it's age. Tomorrow it could be citizenship, income, or gender.

The EU says age is just one use of the wallet — the same design verifies anything. Often that's a real improvement over paper: proving you're eligible to vote, that you live in a school's catchment area, or that you qualify for a youth or senior rail fare, all while revealing less than a physical document would.

But the same machinery turns the other way just as easily: prove your religion, your ancestry, your skin color, that you've never been convicted — to access this service.

I'm uneasy about all of it. Then again, a state that wants to impose such conditions needs no privacy-preserving mechanism, and wouldn't want one. Iran, Russia, China and Afghanistan restrict access to whatever they dislike just fine without it.

Still, the concern stands.

Speaking to reporters on Tuesday in Washington, Dutch Trade Minister Sjoerd Sjoerdsma said the U.S. and the Netherlands share common goals over preventing sensitive technology from ending up in dangerous hands.

However, "elements in that Act seem to suggest that the United States might take control over some of these decisions that affect our national security and the way our companies operate," he said. If the excellent cooperative working relationship with Washington "becomes cooperation by force... that is undesirable from our point of view," he added.

—Reuters

This is the context imho:

You are the Netherlands. Your neighbor and EU partner, Denmark, was just threatened with war over Greenland. You too have a couple of islands, like Curacao, that belong to the Kingdom of the Netherlands, and happen to be in Trump's back yard. The US administration has made clear that no treaties, no international law has value, only power. Why would you give up control over ASML, your most powerful leverage point?

Do we need online age verification?

This is partly an ideological question.

If you think age verification should not exist at all, the technical details won't matter to you. No implementation will be acceptable, because the objection is to age gates themselves, not to any particular mechanism.

I am not in that camp.

A 9-, 10-, or 14-year-old is not ready to wander the open internet without limits. This isn't just a matter of parental taste. Children and teenagers are still developing the cognitive, emotional, and social skills needed to handle manipulation, addiction loops, sexual content, gambling mechanics, grooming, harassment, algorithmic radicalization, and the rest of what adults themselves often struggle with.

Isn't it the family's job to set the limits?

Yes and no.

When children are very young, parents can set strict boundaries. But as kids move into their teens, parents also have an obligation to loosen them. Teenagers need spaces where they can act independently, make decisions, and talk to others — where they can learn to navigate the world without a parent looking over their shoulder.

The question is whether we can build online spaces where that gradual freedom is possible.

"I raised my kids to be smart and self-confident, and they would never do X."

Maybe. I hope I did too. But not all children are the same. They don't share the same temperament, support, confidence, parents, or protection. And even grounded, intelligent teenagers are vulnerable at times.

We already accept age restrictions elsewhere. Children can't drive, drink, gamble, or enter certain venues before a certain age. It is not absurd to think parts of the internet should be age-restricted too.

The hard question isn't whether age limits can ever be legitimate. It's how to enforce them without turning the internet into an identity checkpoint.

Is age verification the first step to mass online surveillance?

It can be.

Most people assume age verification means scanning an ID, uploading a passport, taking a selfie, or submitting to a face scan — which is exactly what many services already ask for.

Implemented that way, the critics are right to be alarmed.

To prove to a porn site, a gambling site, an online liquor store, or a religious forum that I'm an adult, I should not have to hand over my name, date of birth, ID number, face, address, or passport. That is a dangerous amount of information to give any private website, let alone one dealing with sensitive content.

There is another familiar pattern: sign in with a trusted third party.

A site might ask me to authenticate through my bank, my Google or Apple account, my mobile operator, or a government identity service. That avoids handing the site my documents, but it creates a different problem: now the identity provider learns which age-restricted sites I visit.

That's not much better.

In one version, the website learns who I am. In the other, the identity provider learns where I go. Both are scary.

But neither is the only way to do this.

The better primitive: a signed age attestation

A better design starts from a simple idea: prove only the thing that needs proving.

The website doesn't need my name, my date of birth, my ID number, or whether I'm 19, 37, or 74. It only needs to know whether I clear a threshold:

age >= required_age

The easiest way to picture this is a digitally signed attestation.

Take the offline version:

1. You go to a government office.
2. You show your passport or national ID.
3. They issue a card that says only one thing: "over 18".
4. The card carries official seals, signatures, and anti-forgery features.
5. You show that card at the entrance of an age-restricted venue.
6. The venue can confirm the card is genuine without learning your name, date of birth, or ID number.

The digital version is the same idea, with cryptography. An authorized issuer verifies your age once and issues a signed credential:

{
  "claim": "age_over_18",
  "value": true,
  "issuer": "Trusted Age Attestation Provider",
  "valid_until": "2027-12-31"
}

The issuer signs it:

signature = Sign(issuer_private_key, attestation)

A website can later verify it:

Verify(issuer_public_key, attestation, signature)

The key property: the website never has to contact the issuer. It only needs to know the attestation was signed by a trusted issuer and is still valid. And the issuer never learns where — or whether — you used it.

This is the core of the EU approach. The EU Age Verification Blueprint describes a system built on Proof of Age attestations, relying parties, attestation providers, age-verification apps, and trust lists. It is aligned with the European Digital Identity Wallet architecture and lets users prove they are over a certain age without disclosing their exact age or identity. ^{1 2 3}

Selective disclosure and zero-knowledge proofs

A signed attestation is already far better than uploading an ID to every site. But a subtle privacy risk remains.

If the wallet presents the same signed credential to many websites, those sites may be able to correlate visits. Even without my name, they could learn that the same anonymous adult visited site A, site B, and site C.

That's why the stronger version uses selective disclosure or zero-knowledge proofs. Instead of showing the underlying attestation, the wallet proves a statement about it:

I hold a valid Proof of Age attestation, signed by a trusted issuer, that proves age >= 18.

...without revealing the attestation itself.

The EU technical documentation describes this as generating a zero-knowledge proof from a Proof of Age attestation: the app encodes the attestation as private input to a circuit, uses public inputs such as the attestation provider's public key, and produces a zkSNARK proof. ^{4 5}

That's a big deal.

It means the privacy-preserving version isn't:

Here is my ID.

It isn't:

Here is my date of birth.

It isn't even:

Here is my signed age credential.

It's closer to:

Here is cryptographic proof that I hold a valid credential proving I am over 18. You can verify the proof, but you learn nothing about who I am.

That's the right direction, and the signs are that the EU is getting it right.

What privacy advocates should focus on

None of this makes the EU system automatically safe. A privacy-preserving architecture can still be ruined by bad implementation.

Things that would break the promise:

• stable identifiers reused across websites
• the issuer being contacted on every age check
• centralized logs of verification events
• wallet telemetry recording which relying parties requested proofs
• websites demanding more attributes than necessary
• weak wallet security
• poor UX that nudges users into oversharing
• browser or device fingerprinting that links otherwise anonymous proofs
• revocation checks that reveal where credentials are used
• closed, unaudited national implementations

So instead of fighting a system that is built to preserve privacy, we should be fighting to put the right checks in place — the ones that guarantee the implementation actually honors it.

It’s time for "the opposite of doomscrolling” — a new Linkfest, in which I sort through the planet-wide digital rummage-sale of the Internet to locate the finest items of culture, science and technology, just for you.

I really enjoy The Linkfest. I suggest you subscribe too.

Open Tab: Kevin Kelly The radical optimist on starting Wired, stories from the early internet, originating 1,000 True Fans, and why the only way to steer technology is to use it https://on.substack.com/p/open-tab-kevin-kelly

Some people are worth listening to. I'm tired of overnight influencers, and people who somehow are considered deep thinkers because they made a lot of money.

We don't have an information problem. We have a scientific literacy and trust problem.

I agree. Kids learn science as a set of established facts, formulas, and historical discoveries.

Best case is they come away from high school aware of some sequence of wrong theories eventually replaced by the correct one. Atoms were indivisible solid spheres, then we discovered they contained electrons, then protons and neutrons, and finally quantum mechanics revealed "what atoms really are".

They almost always miss that scientific theories are rarely discarded because they are "false." Scientific theories are models with a limited domain of validity and as new evidence appears, we develop theories that explain a wider range of phenomena while preserving the successful predictions of earlier models where those models already worked.

Students learn the fun anecdotes (Newton was sitting under a tree), but no attention is paid to how scientific knowledge is actually produced. The scrutiny, the debates, how they were resolved, what scientists could not know at the time a debate was resolved.

I think it's more important for a 17-year old to finish school knowing why peer review matters, how to read a research paper, or why a single study is almost never the final word on a subject, than of being able to calculate the distance traveled by an object thrown in the air at a 45 degrees angle in the North Pole or what happens if a solution of calcium chloride is mixed with a solution of sodium carbonate or how to calculate an integral.

They should be taught the difference between a hypothesis, a model, a law, and a theory, and how scientific theories evolve as new evidence accumulates. That disagreement is a normal part of science: competing ideas are tested, challenged, replicated, and gradually accepted or discarded based on evidence rather than authority. To treat science as the best available model to explain the world, why we need such a model, and how to compare models.

Understanding this process is more valuable than memorizing isolated facts, because it equips people to evaluate new claims, recognize weak evidence, and distinguish genuine scientific consensus from speculation or misinformation.

GigaOm, was one of my favorite feeds in my RSS reader.

Your voice at The GigaOm Show, and your appearences in Gillmor Gang, was good company during commute and slow weekend mornings.

I appreciated your grounded views, your intellectual honesty, and you were one of the few stars of that era I still appreciated and respected.

https://om.co/2026/06/24/1966-2026/

Farewell, Om. You will be missed.

In 2024, Farcaster was the most decentralized it had ever been: a peer-to-peer network of hubs that were, at the protocol level, peers. My hub running on a Raspberry Pi at home, your hub on a VPS, Merkle’s hubs powering Warpcast, Neynar’s hubs powering various independent apps — they were all peers. Not equal, because network position, capacity, reliability, and importance mattered, but peers.

A year later, in spring 2025, Farcaster migrated to Snapchain.

Snapchain introduced globally ordered blocks, consensus, and, most importantly, higher throughput. Throughput was the weak point of the hub approach, and Snapchain fixed it in order to allow Farcaster to grow from tens of thousands of users to millions of users. But it sacrificed the one unique feature Farcaster had: decentralization.

The core team’s North Star was simple: grow 1000x or die. In pursuit of high growth, they introduced a number of additional client-side features: Frames and Mini Apps, wallets, and Sign in with Farcaster. What used to be a principle — that protocol changes should not be introduced unless a feature has matured — was forgotten, and protocol changes were introduced overnight to support things that looked attractive product-wise, like Farcaster Pro. Fees were reduced to practically zero, despite the original thesis that fees are the friction required to fight spam and abuse of network resources.

All these features made building alternative clients harder and harder, not to mention that the lines between “the protocol” and “clients” were blurred: Farcaster is not the protocol anymore; it’s the client.

These were good features. Fun to use and build for. But the expected growth never came, and all we are left with is a relatively small social network of nice and interesting people, operated by a company.

It’s a nice place to be, and it’s where I prefer to hang out, but it’s no longer something I’m passionate about. I wouldn’t wear a Farcaster T-shirt today. I wouldn’t try to recruit new users. I removed “I’m on Farcaster” from my X account.

Can we go back?

Which brings me to Jack Shephard’s words in the Lost Season 3 finale: We have to go back!

What if Farcaster went back to a hub-based architecture: simple, peer-to-peer, truly decentralized, where it’s easy to run a peer, easy to build self-hosted bots, and easy to build a client?

No bells and whistles. No Mini Apps. No assumption that every client must become a wallet, browser, app host, and social feed at the same time. Strip the network back down to the basics: identity, casts, replies, follows, reactions, and low data retention that makes home hosting feasible.

Then we can rethink Sign in with Farcaster, long-term archiving, scaling, storage fees, app embedding, and everything else. Maybe growth will come at some point in the future, maybe not, but as long as there are a handful of people running a hub at home, the network will be there.

This is not 2024. We know more now. We have seen what worked and what did not. We are not after 1000x growth at any cost. We have new tools for building software, especially when the protocols involved are simple. We can do better than the last time.

Personally, I would be very enthusiastic about this prospect.

The most notable change is the installation bundles come with a nice set of themes, as well as some demo content:

# Install
brew install vrypan/tap/bckt

# Create a test directory and initialize a new blog
# with the demo microblog posts and the micro theme
mkdir test && cd test
bckt init --theme micro --demo microblog 

# Start the local http server to preview it
# (the static pages are in the html/ directory)
bckt dev

Use --demo microblog to test how it looks with short, titleless posts and --demo articles to see a version with longer articles, closer to a typical blog post. But all themes will work nicely with both types of content.

You will probably want to use an AI agent to create your own theme. There is an AGENTS.md that will make this very easy.

For example, let's use Max Böck's blog, which has a really nice design.

cd in your blog directory and try prompt like this:

- Read https://github.com/vrypan/bckt/blob/main/themes/AGENTS.md
- Check themes/* to see how the existing themes are structured.
- create a theme inspired by https://mxb.dev/blog/ 

This is a great example why the EU must try not to depend on AI developed/operated outside of its borders, even if it's inconvenient at times.

That extra line could be hidden, used by the terminal itself, or made writable by the host. In its normal “indicator” mode, the terminal used it for local state: cursor position, printer status, modem status, and similar information. But in host-writable mode, software on the host side of the terminal connection could write directly to that line. ²

The two relevant control sequences are DECSSDT and DECSASD. ³

# Make the status line host-writable
printf '\e[2$~'

# Send subsequent output to the status line
printf '\e[1$}Build running…'

# Return subsequent output to the main display
printf '\e[0$}'

DECSSDT selects the status-display type:

CSI 0 $ ~   no status line
CSI 1 $ ~   indicator status line
CSI 2 $ ~   host-writable status line

DECSASD selects which display receives subsequent characters:

CSI 0 $ }   main display
CSI 1 $ }   status line

It's a surprisingly elegant primitive. A program could use it for progress, mode, host name, current job, debug state, deployment environment, or a persistent “you are in production” warning, without stealing a row from the application, rewriting the prompt, or relying on a terminal multiplexer.

I wasn't able to find a good historical screenshot of a real application writing to the host status line, but you can see it displaying status info in this Capo's Tech video ^{4 5}

Can we bring it back?

The idea feels familiar even if these particular CSI sequences are rarely supported today. We have reinvented the same feature in tmux status lines, Zellij bars, and prompt frameworks because the shape makes sense.

But those are all tool-specific solutions.

It would be great to see modern terminals support DECSSDT/DECSASD again. I think many apps like starship, build environments, package managers and so on would take advantage of the feature if terminal emulators supported it.

Image sources:

• Jason Scott: https://commons.wikimedia.org/w/index.php?curid=29457452
• Tom Page: https://commons.wikimedia.org/w/index.php?curid=98843032
• Capo’s Tech: https://youtu.be/EjJTog15Izs?si=aotLJ8Sb1QGcx2_H&t=426
• LGR: https://www.youtube.com/watch?v=RuZUPpmXfT0

This is the "chilling effect", baked into a product.

As a side-note, if you go IMSLP, you will learn a) that the site is powered by mediawiki and CC, and b) you have to pay to download anything.

I hate copyrights. Copyrights limit creative people.

I'm using a Raspberry Pi 3B with a UnicornHD HAT. Both outdated, but fine for what I'm building, and I like the limitations they impose.

The clock works. The color scheme changes from bright white-ish at noon to dim blue at night. The location is determined by looking up the gateway's IP. Then, based on lat,lon and time, it calculates the position of the sun, and adjusts the color/brightness.

There is also an indicator on the right, showing day/night/dawn/dusk hours which also adjusts automatically.

It can rotate, but I'll have to connect a gyrometer for this to work automatically. Todo.

Works as an AirPlay receiver using SharePlay, and will display artist/title when a track starts. Will add Spotify support too.

I asked codex to parse all my blog posts and get quotes that I have or I could have said, and I'll display them on random times. Needs work, and more personalization, these are intended to be from me to her. Will add some internal jokes, things we say to each other, and may also make some depend on day/time/season/weather. At first it looked like a cool idea, not sure if it will make it to the final version.

I don't want to rely on cloud services, this has to be self-sufficient. I'm currently looking up the network gateway's IP to determine the location using ipinfo.io but I'll find a way to either manually input it, or add a GPS module or something.

While doing various experiments, I got down the rabbithole of music boxes. It would be nice if it also worked as a music box, right?

And I found this amazing project I had no idea about, called Muro Box. Wow, so cool and so beautiful. This is the type of smart devices I would love to build some day, not consumer electronics, but things that are hand crafted, with character andattention to detail and beauty.

Muro Box lets you compose, play, and schedule your favorite melodies. With MIDI control and a patented mechanical design, a single music box can now perform unlimited custom songs—not just short loops.

Anyway, with this and that, I spent the last two days building a music box player. It's a program that will read a MIDI file, and play it as if it were a real music box, with a drum and a comb. I knew nothing about MIDI and sound engineering, but a learned quite a bit, and the result is not bad at all. I'll put it on GitHub once it's a bit more polished.

Years ago, I built a digital desk clock using a Pi Zero and a Micro Dot pHAT. Probably an overkill to use a whole computer as a clock, but it has turned out to be very convenient, it’s easy to read day and night, and I like the style.

Lately, it started freezing. No idea why, my guess was the OS needed to be updated, or even better re-installed —I don’t have a clear log of what this Pi Zero has been through all these years, but for sure it was also used as a DNS (pi-hole) at some point, and as a tailscale gateway at some other.

The problem is my clock was a Python script using a library that has not been updated for at least 4 years. Would it work with a much newer version of Pi OS?

It did not. I could not even install it.

So, I cloned it, and used Claude to port it to Zig. I picked Zig because the resulting binaries are small, and I can also cross-compile on my MacBook Pro (waiting for Pi Zero to compile would not be fun). It took me an afternoon, a couple of manual interventions, and I had my Zig port. The examples compiled, and run perfectly on the latest Pi OS (32-bit).

And since I’m not the one writing the code, why not add some flavor? Let’s have the digits scroll up when they change.

Not bad for a project that took an afternoon. I love it how I can make and fix little things that wouldn’t be worth the time and effort without AI-assited coding.

Eric Raymond’s “The Cathedral and the Bazaar”¹ described two fundamentally different ways of building software. The Cathedral represented centralized, carefully planned development directed by a small group of maintainers. The Bazaar represented open collaboration: large communities, public iteration, distributed labor, and software evolving through many contributors.

For decades, the Bazaar became the dominant cultural myth of open source. Public repositories, pull requests, and community participation were not just practical tools, but moral ideals. Good software was expected to emerge from openness and collective effort.

AI-assisted software development is changing the economics and the ergonomics behind that model. Implementation becomes cheap, and coordination becomes expensive. A single developer equipped with modern tools can now produce systems that previously required teams.

At the same time, software is becoming increasingly personalized: tailored to one person’s workflow, infrastructure, preferences, and habits. Instead of building generalized tools for the widest possible audience, developers increasingly build software that fits their own environment perfectly. Others may still read the code, fork it, or borrow ideas from it, but local modification often becomes cheaper than upstream coordination.

The new model is a kitchen.

Every kitchen evolves around the habits of its cook. Tools sit where they are convenient. Ingredients are substituted freely. Recipes are modified on instinct. Two people may start from the same dish and end up with completely different results.

Unlike the Bazaar, a kitchen is deeply personal. Recipes are shared freely, but kitchens rarely converge into a universal standard. Visitors may admire another cook’s techniques, yet still return home and prepare the dish their own way. In the Kitchen model, open source becomes less like public infrastructure and more like published craft: software as personal utility, openly visible, endlessly adaptable, and increasingly authored by individuals rather than communities.

In the Bazaar model, openness was mainly a way to coordinate people. You opened the codebase to attract contributors, spread work across many developers, avoid duplicated effort, and slowly build shared infrastructure.

In the Kitchen model, openness serves a different purpose. It provides visibility, learnability, and independence. Value shifts from “others can help build this” to “others can understand, adapt, and reclaim this.”

Source code starts to resemble recipes more than public construction projects. Most people do not submit patches to a cookbook, yet recipes remain enormously valuable because they transfer techniques, preserve knowledge, and provide foundations others can adapt to their own tastes and environments. The code is open not necessarily so everyone can co-author it, but so anyone can study it, modify it, and make it their own.

This also changes the meaning of forks. In the Bazaar, forks were often viewed as failures of governance or coordination. In the Kitchen, forks become normal and healthy:

• “I adapted this for my setup”
• “I removed features I don’t need”
• “I rewrote this around my workflow”

Forking becomes analogous to modifying a recipe² at home.

Software evolves through local adaptation rather than centralized consensus. A developer will remove features, rewrite workflows, or optimize entirely around their own infrastructure because doing so is now cheaper than negotiating a generalized solution acceptable to everyone.

This model still depends on public circulation of ideas. Even if code contributions decline, people still copy ideas from each other constantly through imitation, recombination, critique, and inspiration.

Much of programming history already worked this way:

• Unix customization culture where ingredients were expected to be mixed in different ways
• shell workflows and personal scripts
• dotfiles designed to show others how a system is configured but rarely adopted one-to-one

These are often highly personal systems shared publicly, not collaboratively engineered products.

Open source remains essential because it preserves agency: the ability to inspect, repair, continue, and reshape software independently of its original author. The result is a world where software is increasingly personal, but where ideas, techniques, and tools still circulate freely between individuals, much like recipes passed from kitchen to kitchen.

Update (15-May-2026): Other people have described the same or a similar mental model:

Drew Breunig calls it "the Winchester Mystery House":

The ideas crystallized in "The Cathedral and the Bazaar" helped kick off a quarter-century of open source innovation and dominance.
But just as the internet made communication cheap and birthed the Bazaar, AI is making code cheap and kicking off a new era filled with idiosyncratic, sprawling, cobbled-together software.
Meet the third model: the Winchester Mystery House.

—The Cathedral, the Bazaar, and the Winchester Mystery House³

And Thomas H. Ptacek, calls it "the Emacsification of Software":

First, it's personal software. Most of it will be useful only to its creator, and then forgotten, just like the dozens of obsolete little elisp programs littering my .emacs. Personal software defines the ethos of Emacs, which was carefully designed over decades to nurture these kinds of tools. "Emacsification" clocks that everything now works this way, not just baroque text editors.

—The Emacsification of Software⁴

If you spend as much time as I do in the terminal, you probably depend on your shell history too. Being able to repeat a complex command that you remember you typed a month ago, is extremely valuable —no wonder why I’ve set HISTSIZE=10000.

While it is convenient to use your shell history as part of your long term memory, the downside is things that shouldn’t be there, end up there: A command you prepended with API_KEY=..., a quick and dirty curl --user "name:password", a PGPASSWORD=... psql, an ALTER USER USER() IDENTIFIED BY ..., and so on. And they are all probably saved in shell or app history file.

This is not good, obviously. Credentials should not be saved in places where a malicious program can just read them, and they should not be preserved in backups.

That’s why I built shg (short for SHell Guard), a small program that scans my shell history (and other history files) for entries that look like API keys, passwords, bearer tokens, credential URLs, and private keys and alerts me.

I’ve set it up to do a quick scan when I start a new shell and (I think this is the coolest part) also check every command I enter in zsh and catch secrets before they ever land in ~/.zsh_history.

Some tips:

• run shg-config discover to find and configure history files that are not part of the default scan list.
• you can adjust the output and the severity level using --level, --one-line, --json and other options. Check shg scan --help for more details.
• If you keep getting reports for entries that you don't mind, add them to ~/.config/shg/ignore.local.shg. (See the default ignore file here).

If you use shg and you like it, give it a star on GitHub! 🙏

Recently, I've been trying to shape the cli arguments of a tool I'm building in Zig to fit zli and zig-cli.

It's not the first time. cobra has its own opinions in Go, clap in Rust, docopt in Python, and so on.

One library doesn't support repeated arguments.
Another doesn't allow ordering the args alphabetically in help.
This one doesn't support arguments with optional values.
That one has a small UI bug.
Another won't fold long descriptions.

I kept adding small hacks to bring the implementation closer to what I had in mind, but a) it was not 100% there, and b) it felt like a hack.

Writing a cli parser is not rocket science. A coding agent like codex or claude can definitely do it, as long as you provide it with clear specs. Which is what I did, since I already had a lot of boilerplate code.

Twenty minutes later, everything works exactly the way I want it to work, and now I can tweak it at will, and re-implement it in the next project, regardless of the language used.

A library of agent specs

Instead of rediscovering the requirements every time, I put them down in a form that AI agents can use.

That's the idea behind github.com/vrypan/agent-specs. It will probably become a small collection of specifications designed to be used by agents.

One can think of it as a higher-level code library. Instead of the language-level import/include/use, you have a spec for an agent.

> Implement cli arguments and options according to specs/cli/CLI.md.

Each section of CLI.md has an identifier, like CMD-SUBCOMMANDS, FLAGS-SHORT-VALUES and OPT-COLOR. This makes it easy to tell the agent, use this, don't implement this, override that. There are also test cases, to help the agent test the implementation.

So, you could also ask something like this

> Use specs/cli/CLI.md as the CLI parser specification.
Implement all required sections.
Do not implement OPT-COLOR.
Translate specs/cli/tests.yaml into automated tests.
Report any deviations.

We often treat determinism and predictability as synonyms, but they are not the same.

A system is deterministic if the same starting conditions always lead to the same result. A system is predictable if we can actually foresee that result with the tools, time, and knowledge we have.

Determinism is a system characteristic.

Predictability, on the other hand, often depends on our capabilities, and it usually exists on a spectrum. Weather is a good example. The laws of physics governing the atmosphere have not changed, and they are deterministic. Yet our ability to predict the weather has improved over decades simply because our measurements, models, and computing power improved.

But it's not always on us. Stephen Wolfram has described the concept of computational irreducibility ¹. A system is computationally irreducible if the only way to know its future state is to simulate every step. There are also chaotic systems where tiny measurement errors grow rapidly, making them practically unpredictable.

Some systems are both deterministic and predictable, like planetary motion over short time scales. Others are deterministic but not predictably so in practice, like weather or turbulent flows. Conversely, some systems are not deterministic at the level of individual events but are still predictable statistically, such as casino games or population averages.

In essence: determinism does not guarantee predictability, and predictability does not require determinism.

Back to coding…

From the perspective of someone who needs a piece of software, development has never been deterministic. When you ask a software developer to build something, you cannot predict exactly what code they will write, how long it will take (so many jokes about this…), or which edge cases will fail first. The same is true when you ask an AI agent. Both are problem-solving processes operating under uncertainty.

One can argue in favor or against the competency of humans or LLMs when it comes to coding, but determinism has never been a human trait.

In most cases, developers build software to satisfy other people’s needs, and what these people really care about is whether the resulting code is predictable enough to rely on: whether the system behaves correctly most of the time, whether failures are visible, and whether they can be fixed quickly.

This distinction is important. From a software developer's pov, asking an LLM to "build a program that sorts 1000 numbers" may not have a predictable result (code). But the end user only cares if the resulting program will always sort any 1000 numbers correctly.

And then there is the environment. Modern software runs on stacks that are far more complex than any single developer can fully reason about: hardware, kernels, drivers, libraries, network conditions, configuration files, container layers, dependency versions. So, even if, as a developer, you write the code to do excatly what you want it to do, in a totally predictable way, running the code may yield less predictable results. While deterministic, the system as a whole is so complex that its behavior cannot be predicted perfectly in advance.

We have quietly accepted that bugs are a natural part of software development ² (i.e. there will be cases where it behaves unpredictably), because we recognize the complexity of the endeavor. Instead of expecting perfect foresight, the industry built practices around uncertainty: tests, staging environments, observability, rollbacks, reproducible builds.

So, the meaningful question is not about determinism. The meaningful question is which workflow produces more predictable outcomes under real conditions, and which human or AI is a better fit at each case/stage. ⁵

Some final thoughts.

It’s worth looking at how we build some of the most safety-critical software. DO-178C is the “Software Considerations in Airborne Systems and Equipment Certification”. It is a key document in the aeronautic industry, providing guidelines for the development of safety-critical airborne software.

The approach of DO-178C is based on the formulation of appropriate objectives and on the verification that these objectives are achieved. The DO-178C authors acknowledged that objectives are more essential and stable than specific procedures. The ways of achieving an objective may vary between companies, and they may vary over time with the evolution of methods, techniques, and tools. DO-178C never states that one should use design method X, coding rules Y, or tool Z. DO-178C does not even impose a specific life cycle. ⁶

DO-178C is objective-oriented: the focus is on formulating objectives and verification that the objectives are achieved, a framework that could work both for human coders and LLMs.

Nothing could be further than this, when it comes to random number generators. Smart people with deep and broad knowledge have been studying the field for centuries, you can't just show up and expect you will build something better, or even decently good, just like this.

But during the last 10 days that I've (obsessively) been on this journey I've learned so much. (ChatGPT and Claude have allowed me to learn and experiment at a pace that would be unimaginable a year ago.)

Yesterday I started reading again (last time I tried, I stopped after the second chapter or so) Wolfram's "New Kind of Science". It will take me some time, but there are so many concepts and ideas I've long been fascinated about, but never went to the depths Wolfram goes.

On the side, I'm studying a 1984 paper, on "Algebraic Properties of Cellular Automata" now. Algebras were one of my favorite topics when I was studying math, and I feel lucky to have the tools, to (try to) understand it: https://content.wolfram.com/sw-publications/2020/07/algebraic-properties-cellular-automata.pdf

(It's sad that so few people get to learn what Mathematics really are: a tool to describe and study concepts that often push the boundaries of our minds.)

So, Rule30RND was ok as a fun experiment, but not a PRNG that someone could take seriously.

I kept tinkering, as if I was playing a game: change this and that, run the tests, check my score.

Side note: after I published the last post, I realized that my test scripts had fundamental flaws, like adding text headers in the randomly generated bytes.

Radius-2

No matter how hard I tried, it was obvious that a Rule 30-based algorithm would not pass BigCrush unless I changed it so much that would become something else with a sprinkle of CA.

Now, Rule 30 works like this: If C is our bit, L is the one on its left and R the one on its right:
new_bit = L XOR (C OR R)

That’s a "radius-1 CA". What if I tried with a radius-2 CA, that uses two bits on the left and two on the right?

Unfortunately, there is much less literature for radius-2 than radius-1 CAs. After some search that did not return a documented good candidate for what I wanted to build, and a few failed experiments, I decided to extend Rule 30 in a “symmetric” way.

new_bit = (L2 XOR L1) XOR (C OR (R1 OR R2))

This gave significantly better results.

Not exceptional. The new algorithm failed 5/15 SmallCrush tests (Gap, SimpPoker, CouponCollector, WeightDistrib, HammingIndep).

But these are the tests I might be able to fix with a diffusion function.

Searching for a diffusion fucntion

I wanted a diffusion function, so I let Claude test 7 different functions, run the tests, collect the results, and let me know when it was done.

The winner was the “Hybrid” approach that combines rotation, multiplication by the golden ratio, and shift-XOR:

func mix(x uint64) uint64 {
    x ^= bits.RotateLeft64(x, 13)
    x *= 0x9e3779b97f4a7c15  // Golden ratio constant
    x ^= x >> 27
    return x
}

SmallCrush is the first step, but I needed it to pass BigCrush.

And, YES! My rule-30-radius-2-diffused algo scored 160/160 on BigCrush for the first time!

Staying true

Now, this worked, but it was also cheating: I applied mix() to every state evolution: s1, s2=mix(rule30(s1)), s3=mix(rule30(s2)), ..., so this was no longer a CA algorithm.

What if I applied mix() only to the output? I.e. keep a pure Rule 30, radius-2 algorithm that generates states s1, s2, ..., but return mix(s1), mix(s2), .... Would this work?

IT WORKED! IT WORKED!

And it was also 6% faster.

I present you “R30R2”

Along the way, I fixed some annoying Makefile issues, optimized how Read() reads data from the state, and tweaked a few things here and there.

I was ready to release it, but when “Rule 30” is mentioned in literature, it means a radius-1 CA.

I decided to rename the project, the documentation, the function names, etc. And it's name is... R30R2.

R30R2 is a radius-2 Rule 30-based PRNG with a diffusion function applied on output. It scores 160/160 on BigCrush, and is 2× faster than math/rand/v2.

You can find it at https://github.com/vrypan/r30r2/

🎉🍾🍻