decayfmt: The File Format That Corrupts Itself Every Time You Open It

A Rust CLI that makes files worse every time you look at them sounds like a bug report. It's actually the whole point. decayfmt, posted to r/ClaudeAI by u/racialminority on August 20, 2026, racked up 957 upvotes and 121 comments in about half a day — not because file corruption is useful, but because the thread that formed around it turned into a genuinely good conversation about DRM, entropy, and how diffusion models actually work.

TL;DR — what people actually ask about decayfmt

What decayfmt actually is

The pitch, in the creator's own words on Reddit: "A file format that corrupts itself a little every time you open it. Every open permanently damages the file on disk, by an amount baked into the filename, before it is ever shown to you. There is no recovery from the file alone." Made, per u/racialminority, because the idea "sounded very fun" a few weeks earlier — "Kinda analog."

Mechanically, per the GitHub repo: decayfmt defines two file types, .idcy for images and .tdcy for text. The filename carries an instability parameter — photo.idcy3, note.tdcy7 — that sets a per-byte corruption probability of roughly 1 - e^(-x/10). At x=1 that's about 9.5% of bytes touched per open; at x=10, roughly 63%. Images corrupt their RGB channels independently while leaving the alpha channel alone, so decay reads as visible color noise rather than the image turning transparent. Text swaps bytes for random printable ASCII while preserving the file's length — so a decayed text file stays readable-as-a-file-object even as its content dissolves into noise.

Crucially, the corruption happens on disk, before display — decayfmt open mutates the actual bytes of the file, then shows you the now-damaged version. There's no undo command. The only way to preserve a file's current state is to keep a copy from before you opened it — which, as the comment section noticed fast, is also the format's whole vulnerability.

The real critique: this is the reader's decay, not the format's

The single most upvoted technical thread, from commenters including u/Alone-Low3274 and u/rgb_panda, cuts straight to the point: decayfmt isn't a property of a file format at all — it's a quirk of the one program OP wrote to open files with that extension.

That distinction matters more than it sounds. A file format is a specification for how bytes are structured; a reader is one particular program that interprets those bytes. Nothing about decayfmt's .idcy/.tdcy byte layout requires corruption on read — the corruption is a side effect bolted onto one specific implementation of open. Which means every workaround Reddit found in minutes is trivial by design, not by exploit:

• Copy the file, open the copy. The original stays pristine forever.
• Set the file to read-only. The current build refuses to touch read-only files — a courtesy, not a lock.
• Screenshot the output. (u/racialminority's reply, playing along with the bit: "dont do that.")
• Fork the repo and comment out the decay function. Since the corruption logic ships as open-source Rust under an MIT license, nothing stops anyone from removing the one line that calls it.

This is worth sitting with because it's the exact shape of a much bigger, much older problem: DRM's fundamental unsolvable issue, shrunk down to a toy example. Any scheme that tries to enforce a rule about data through the program that reads it — rather than through something cryptographically bound to the data itself — only holds as long as nobody controls their own copy of the reader. The moment the reader runs on hardware the user fully controls (which is true of basically every consumer device), the user can inspect it, patch it, or simply not run it, and the "enforcement" evaporates. Decade after decade of DRM schemes, region locks, and "self-destructing" message apps have run into this same wall. decayfmt just makes the mechanism legible in about 200 lines of Rust instead of hiding it inside a licensed SDK.

The community's other read on this — "please don't give big tech ideas" — is the same insight wearing a joke's clothing. Commenters like u/PositionTiny7988 and u/Mobile_Pop_62 riffed on Adobe, OnlyFans, and planned obsolescence, and the worry underneath the joke is real: software that appears to gate access to your own files is a recognizable, historically unpopular pattern, and a viral demo of the concept — however playful — is a reminder of how cheap it now is to prototype. That reminder is a feature of this thread, not a threat that decayfmt itself poses; it's a fun toy with an MIT license, not a shipping product.

The genuinely sharp comment: this is basically diffusion, backward

The best technical observation in the thread came from u/teramoc, and it's worth explaining properly rather than just quoting it: "Fun fact. If you build in a seed, you can reconstruct the image over time back from noise to clear. Get clearer every time you open it. AKA: How AI images work."

That's not a throwaway line — it names the exact structure behind every modern diffusion model. Diffusion image generators (Stable Diffusion, FLUX, DALL-E, Imagen) are trained on a forward process: take a real image, and over a fixed number of steps, add a known, scheduled amount of Gaussian noise until the image is pure static. That's mechanically what decayfmt's corruption function does to an .idcy file — apply noise on a per-byte schedule set by the filename's x parameter, one step at a time, one "open" at a time.

The generative payoff comes from the reverse process. A diffusion model is trained to predict, at each noise level, what was added — and if you know the exact noise schedule and (critically) the random seed used to generate it, you can run the process backward: start from noise, subtract the predicted noise at each step, and arrive back at something close to the original signal. That's the entire mechanism explainx.ai walks through in detail in how diffusion image generation works — U-Net or DiT architectures trained to denoise, conditioned via cross-attention, sampled step by step from static into a coherent image.

decayfmt doesn't implement that reverse pass — its corruption is one-directional and, per the creator, not built to be undone. But u/teramoc's point stands as a correct mental model: a designed decay process and a diffusion model's forward noising step are the same object, and the only thing separating "corrupted file" from "generative model" is whether you've trained something to run the noise schedule backward. u/Ipeeinmysocks made the same connection more bluntly: "It's just stable diffusion in essence" — copy the file at each decay stage, and you have training data for exactly that reversal.

Which is also why the "is it truly irreversible" question landed the way it did. u/Odd_Sale3811 asked whether the corruption is irreversible in the cryptographic sense; u/racialminority answered plainly: "its stochastic so nope." That's honest, and it's the right answer for a single decayed file with no history — a stochastic byte-flip has no deterministic inverse function or key that undoes it. But "stochastic" and "cryptographically unbreakable" aren't the same claim. If an attacker held copies of a file at several decay stages — exactly the setup u/Ipeeinmysocks described — they could in principle train a model against the known corruption probability distribution and statistically reconstruct earlier states with real accuracy, the same way a diffusion model learns to reverse a known noise schedule. decayfmt's honesty about being stochastic rather than claiming cryptographic security is the right call; it's just worth being precise that "not reversible from one file alone" and "not reversible at all, ever, by anyone with enough samples" are different guarantees.

Two more threads worth keeping

Two smaller comments in the thread punch above their upvote count:

u/GeeBee72 on memory: "It's like biological memory, if not destroyed then altered based on current context. Very interesting concept for gating of memories to keep and memories to dispose of." That's a real design question for anyone building agent memory systems today — what should an AI agent's memory keep at full fidelity forever, what should it let decay or compress, and does "context matters more with each recall" describe a feature or a bug for a coding agent's long-running memory. explainx.ai has covered local-first approaches to agent memory in MemPalace; decayfmt's framing — decay as a designed, first-class property rather than an accident — is a useful lens to bring to that design space.

u/101Alexander on determinism: "Fun to think about, but if software isn't determinate then it wouldn't be usable." That's a fair, general engineering point, and it's worth separating from the fun of the demo: production software generally needs to behave the same way twice given the same input, and a file format whose "read" operation has a random outcome is disqualifying for basically any real-world use case. decayfmt isn't trying to be production software — it's closer to generative art with a file extension — but the critique is a good reminder that "interesting behavior for a toy" and "acceptable behavior for a tool" are different bars, and confusing them is a real failure mode in vibe-coded side projects that quietly graduate into something people depend on.

What this is actually worth taking from it

Strip away the "should this exist" debate and decayfmt is a clean, small example of three things explainx.ai keeps seeing in the "built with Claude" corner of Reddit:

1. A coding agent makes a weird, playful idea cheap to try. u/racialminority had the idea "weeks ago" and built a working Rust CLI with a genuinely novel-feeling UX around it fast enough to post before the idea went stale — the same low-friction prototyping loop behind World of ClaudeCraft and other viral "built this over a weekend" showcases.
2. A reader can't enforce a property the format itself doesn't guarantee. This is the DRM lesson in miniature, and it generalizes past file formats — the same reasoning applies to client-side license checks, "tamper-proof" local apps, and any scheme that assumes the person running your code won't read it.
3. Fun demos are still a legitimate way to teach real mechanisms. u/teramoc's forward/reverse noise comment did more to explain diffusion models in two sentences than a lot of formal explainers manage in a page — sometimes the best teaching moment in a technical community is the joke project, not the tutorial.

None of that requires taking "please don't give big tech ideas" too literally — decayfmt is MIT-licensed, 62 stars, and built to be forked and defanged in five minutes. The value here was never the corruption. It was the thread it caused.

Related reading

• How Diffusion Image Generation Works: The Complete Guide
• Airgapped QR File Transfer: Decimen, Fountain Codes, and "This Already Exists"
• "Who Is JSON?" — The Vibecoding Meme Explained
• World of ClaudeCraft: The MMO Claude Fable 5 Built in a Weekend
• terminal-minceraft: Minecraft in Your Terminal, Playable by an Agent
• MemPalace: Local-First AI Memory, Explained
• What Is Vibe Coding, Explained
• Vibe Coding Nightmares: Mistakes and How to Avoid Them

Source: aravpanwar/decayfmt on GitHub · r/ClaudeAI discussion

Repository details (stars, license, corruption formula) and Reddit thread quotes reflect the state of both as of this post's publication date; an actively developed open-source project's star count and code will keep moving.