DEV Community: sky

I put a diffusion model in a stylesheet. No JavaScript.

sky — Mon, 09 Nov 2026 04:16:07 +0000

Try it: metrix187.github.io/diffusion.css · Code: github.com/Metrix187/diffusion.css

Press the button and the stylesheet freezes a seed, turns it into noise, and denoises that into a 16×16 sprite in 12 steps. There is no <script> on the page. View source and check.

Why

People have already put a CPU, digit classifiers and, a few days ago, GPT-2 into CSS. I went looking for a diffusion model and couldn't find one, so this is my attempt.

The problem: CSS has no loops

Denoising is a loop. Each step needs the previous step's output, and a custom property can't refer to itself.

So the sampler is unrolled. Every step gets its own copy of the arithmetic, and every intermediate value gets its own registered custom property. A hidden unit looks like this:

@property --Ba0 { syntax: "<integer>"; inherits: true; initial-value: 0 }

/* first unit of the network used by step 2 */
--Ba0: max(0, (51096.5 + 25*var(--a108) - 26*var(--a123) - 31*var(--a126) /* 80 more terms */)/512);

Registering the property matters. An unregistered custom property is just text, so each var() would paste in the whole expression behind it and the stylesheet would blow up. A registered <integer> is computed once, rounded, and passed on as a number. There are 12,518 of them.

Seed and noise

The seed is a counter that a hidden checkbox pauses, so the moment you press is the random seed:

@keyframes spin { to { --seed: 15813250 } }
.app { animation: spin 211s linear infinite }
.app:has(#go:checked) { animation-play-state: paused }

Each of the 768 pixel channels then hashes that seed with mod() four times and sums the draws, which gives roughly Gaussian noise. That is the static you see before pressing.

The network rule only matches while the box is ticked, so nothing is computed until the seed is frozen. After that, one @keyframes rule points the 256 pixel elements at each sampler state in turn.

The model

Eleven small MLPs, one per noise level, trained in PyTorch on ten hand-drawn sprites that get recoloured to a random hue for every sample. Then they are pruned and rounded to integers: 202,863 weights, each one a literal inside a calc().

Two things that went wrong

Rounding. CSS rounds a calc() in an <integer> context to the nearest integer, but browsers don't agree on exact .5 ties. The fix: every division is by a power of two with 0.5 added to the numerator, so a quotient is never a tie. With that in place, a Python sampler using the same integer arithmetic produces identical pixels for the same seed. I checked 40 seeds in Chromium 152 and another 40-odd in Chrome 157.

Blended sprites. The first model produced a muddle of two sprites about a third of the time. Deterministic sampling with only 12 steps drifts between two shapes and never commits. Two changes fixed most of it: spacing the noise levels evenly in log-SNR, and training the later steps on inputs deliberately blended with a second sprite while keeping the dominant one as the target, so they learn to snap to one shape. It is down to about 1 in 20.

What it isn't

Not a loop. All 12 steps are computed when the seed freezes. The animation reveals them; it does not drive the computation.
Not creative. It learned ten shapes and a continuous range of colours. You get new shape-and-colour combinations, never a new shape.
Not tested outside Chromium. It only uses features Firefox and Safari also ship, but I have not run it there.

Numbers


Weights	202,863
Sampler steps	12, deterministic DDIM
Registers	12,518
Possible seeds	15,813,251
File size	5.2 MB, 0.8 MB gzipped
Time to compute a sprite	about 0.13 s

a new privacy tool :3

sky — Wed, 21 Oct 2026 03:24:49 +0000

I made Scrub, a browser tool that blurs the room behind you before you share a photo.

Photos stay on your device. Blurring isn't anonymity.

Try it: Scrub Live Demo

Code:

Metrix187 / unlisted

Reduce background clues in photos shared from home. Browser-based Scrub and manual listing-photo removal guidance.

unlisted

Reduce the background clues in photos you share from home.

Unlisted explores one specific risk: a photo's visible room details may be matched to rental or real-estate listing photos associated with an address. Scrub reduces those details; Footprint helps you check listing sites manually and find removal guidance. Neither tool can tell you that you are safe We have not tested these defenses against Raven, GeoSpy, or other proprietary systems.

Scrub (apps/scrub) — pick a photo, see what in the room would give it away, tap once to blur the room out from behind you, share. runs entirely in your browser. the photo never leaves your device.
Footprint (apps/footprint + workers/footprint-api) — manual search links and per-site removal guides. Automated lookups are largely blocked. Addresses are sent to a Cloudflare Worker for lookup the code avoids storing the address, but Cloudflare handles the request. This…

View on GitHub

Tell me what breaks.

Seven Silent Failures: building an autonomous email agent on Cloud Run

sky — Mon, 31 Aug 2026 18:06:48 +0000

I created this piece of content for the purposes of entering the All Things Agentic Hackathon.

Originally published at quantara.cv.

the thing i built

An agent with no chat box. An email arrives, and it wakes up on Cloud Run, reads the thread, checks my actual calendar, writes a proposal document, and prepares a reply — then stops and asks a human the moment it isn't sure. Nobody types anything. There is no prompt. The email is the prompt.

Gemini 3.5 Flash does the tool selection through function calling, Google's Agent Development Kit runs the loop, and three Cloud Run services keep ingress separate from execution. Pub/Sub carries events between them and Firestore holds the state. The repo is here if you want the actual code.

That's not what this piece is about. This is about the seven things that went wrong, because six of them went wrong quietly, and that turned out to be the real lesson.

the one that shouted

Exactly one failure announced itself. Line endings. I wrote the deploy scripts on Windows, git helpfully stored them with CRLF, and anyone cloning the repo would get bad interpreter: no such file or directory. Ugly, obvious, fixed with a .gitattributes in about ninety seconds.

Every other failure was polite about it.

1. the model that exists, but not here

gemini-3.5-flash returns a 404 on Vertex AI in us-central1. The error says publisher model not found. That sentence sends you hunting for a typo in the model name, which is the wrong place to look — the model is fine, the region isn't. It's only served from the global endpoint.

I found it by brute force, asking three regions in a row. Nothing in the error text points at geography.

2 and 6. iam, twice, the same way

Two separate failures, identical shape. A service account gets created, the very next line binds a role to it, and the bind fails with service account does not exist. It does exist. It just doesn't exist yet — IAM is eventually consistent and the propagation window is tens of seconds.

The first time this bit me, the failure was inside a line ending in || true. I'd written that to make the script re-runnable. What it actually did was swallow the error, skip creating the Pub/Sub subscription, and leave me with a deploy that printed three green service URLs and a completely disconnected pipeline.

Every piece of visible config was correct. The thing simply did nothing.

The second time was Cloud Scheduler, which needs its own service agent to hold serviceAccountTokenCreator on the account it impersonates. Without that grant: no scheduler log, no request at the target, no error anywhere. And while the grant propagates, it fails in exactly the same silent way — so I concluded it was broken and wrote it off. It started working four retries later.

3. gmail won't tell you what arrived

A Gmail push notification contains {emailAddress, historyId}. That's it. No message ID, ever. To find out what actually landed you replay users.history.list from a watermark you stored yourself, and one notification can cover several messages.

I'd built the obvious version, passing the historyId through as though it identified something. Every real trigger 404'd.

The part worth sitting with: every test I'd written before that point passed, because every test supplied the message ID by hand. I had thoroughly tested a code path that production would never take.

4. a container has no idea where it is

datetime.now().astimezone() resolves to UTC on Cloud Run. So "available 9 to 5" quietly became 9–5 UTC, and my agent started offering a prospective client 5 a.m. meetings.

It labelled them UTC correctly, too. The output looked right. It was just useless.

This is the one I'd most likely have shipped, because it passes every test written by someone sitting in the same timezone as their server — which is to say, every test I would have thought to write.

5. the guardrail worked; the output didn't

The agent signed a draft [Operator]. A literal placeholder, in an email a human was one click from sending.

Nothing was broken. The escalation logic was working perfectly the entire time. The tool returned ok=True, because the API call genuinely succeeded. A tool reporting success tells you the call went through, not that what came back was any good — and nobody had read the output yet.

7. i proved it, wrote it down, and shipped it anyway

This is the one I'd lead with.

Pub/Sub delivers at least once, so every event eventually arrives twice. For an agent with side effects that's the difference between one draft and two. I handled it properly: before doing anything, the router performs an atomic Firestore create() on a key derived from the event. The create fails if the key exists, and the failure is atomic, so there's no read-then-write race. I was pleased enough with this that I put the formula in the write-up.

Then I sent two emails at once and the agent wrote two proposal documents for one of them.

Gmail sends one notification per arriving message. Two emails, two notifications — and both replay the same history window, so both surface both messages. I'd keyed the claim on historyId + messageId. Two views of one message, two different keys, no collision, two drafts.

The lock worked exactly as designed. It was guarding the wrong door.

The lesson isn't "handle at-least-once delivery." I had handled it, and I had a proof. It's that a deduplication key has to name the thing with the side effect, not the thing that told you about it. I'd tested Pub/Sub redelivery, which is the easy case and the one I'd thought of. The case that broke it only appears when two messages arrive close enough together to overlap their history windows — which is exactly what a demo does, and exactly what a quiet test inbox never does.

the pattern

Six of seven failures produced no error. Not a caught exception, not a warning, not a log line. Several produced output that looked correct: meeting times labelled with the right timezone, a deploy printing three healthy service URLs, a cron job sitting in the console marked ENABLED.

The common thread is that distributed systems fail by omission far more than by exception. A missing IAM grant and a still-propagating IAM grant are indistinguishable. A created cron job and a working cron job look identical until the day you need it. A tool returning ok and a tool returning something useful are different claims.

Which means the only thing that actually found these was running the real thing against real data and reading the output. Not tests — my tests passed throughout. Watching it work, end to end, and being suspicious of success.

what i'd do differently

Never write || true without logging what it swallowed. That one line cost me a disconnected pipeline that looked deployed.
Assume IAM lags. Poll for the resource before binding to it, instead of assuming that created means usable.
Test in the environment's timezone, not yours. Or better: refuse to have a default. Business hours without a named zone are meaningless.
Read the agent's actual output. Every run. ok=True is not a quality signal, and the placeholder signature proved it.
Name your idempotency key after the side effect. Not after the notification, not after the request. After the thing you'd hate to do twice.

The agent works now. It reads a real inbox, does real multi-step work on real APIs, and stops to ask a human when it isn't sure. That last behaviour is the one I'm most pleased with, and it's the only one that never broke.