A Rust command-line tool called decayfmt, built with Claude Code, has sparked a viral conversation about digital rights management by doing something deliberately useless: corrupting your files a little bit every time you open them. Posted to Reddit's r/ClaudeAI community on August 20, 2026, the project accumulated 957 upvotes and 121 comments in roughly half a day, not because file corruption is practical, but because the thread evolved into a genuine technical discussion about entropy, diffusion models, and why software-based content protection has never worked.

What Does decayfmt Actually Do?

The concept is straightforward but unusual. decayfmt is a file format reader that permanently damages files on disk before displaying them to you. Every single time you open a file, a portion of its bytes gets corrupted according to a decay parameter baked into the filename itself.

The mechanics work like this: a filename like "photo.idcy3" or "note.tdcy7" carries an instability parameter that sets how much damage occurs per open. At a parameter value of 1, roughly 9.5% of bytes get corrupted; at a value of 10, approximately 63% of bytes are affected. For images, the corruption appears as visible color noise in the RGB channels while leaving the alpha channel untouched, so the file degrades visibly rather than becoming transparent. Text files swap bytes for random printable ASCII characters while preserving the file's length, meaning a decayed text file remains readable as a file object even as its content dissolves into noise.

The creator, Reddit user u/racialminority, built the project in Rust under an MIT open-source license because the idea "sounded very fun" a few weeks earlier and felt "kinda analog." The tool is available on GitHub at aravpanwar/decayfmt with approximately 62 stars.

Why Is This Actually About DRM, Not Just a Prank?

The technical community quickly identified the real insight buried in this playful project. Multiple commenters, including u/Alone-Low3274 and u/rgb_panda, pointed out that decayfmt isn't actually a property of the file format itself; it's a quirk of the specific program written to open files with that extension. This distinction cuts to the heart of digital rights management's fundamental, unsolvable problem.

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 or.tdcy byte layout requires corruption on read; the corruption is a side effect bolted onto one specific implementation. This means every workaround the Reddit community found in minutes is trivial by design:

• Copy the file: Make a duplicate before opening it, and the original stays pristine forever.
• Set read-only permissions: The current build refuses to touch read-only files as a courtesy, not a cryptographic lock.
• Screenshot the output: Capture the displayed version instead of relying on the file itself.
• Fork the repository: Since the corruption logic ships as open-source Rust under MIT license, anyone can remove the one line that calls the decay function.

This is worth examining closely because it's the exact shape of a much larger, much older problem. 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.

What Are the Real Concerns This Raises?

The community's other interpretation of decayfmt, expressed partly as a joke but rooted in genuine concern, was "please don't give big tech ideas." Commenters like u/PositionTiny7988 and u/Mobile_Pop_62 riffed on Adobe, OnlyFans, and planned obsolescence. The worry underneath the humor 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 such ideas.

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 reminder that such tools are easy to build 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.

How Does This Connect to AI Image Generation?

The sharpest technical observation in the thread came from Reddit user u/teramoc, who noted something that names the exact structure behind every modern diffusion model. The comment stated: "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".

This observation isn't a throwaway line; it identifies the precise mechanism behind every modern diffusion model. Diffusion image generators like Stable Diffusion, FLUX, DALL-E, and 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 becomes pure static. That's mechanically what decayfmt's corruption function does to an.idcy file; it applies noise on a per-byte schedule set by the filename's 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. 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 behind how diffusion image generation works, with 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 the connection stands as a correct mental model: a designed decay process and a diffusion model's forward noising step are the same object. The only thing separating "corrupted file" from "generative model" is whether you've trained something to run the noise schedule backward. Reddit user 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.

Is the Corruption Actually Irreversible?

When Reddit user u/Odd_Sale3811 asked whether the corruption is irreversible in the cryptographic sense, the creator u/racialminority answered plainly: "its stochastic so nope." That's honest, and it's the right answer for a single decayed file. The corruption is not reversible from the file alone, but statistically, with enough decayed copies collected over time, partial reconstruction might theoretically be possible.

This distinction matters because it highlights the difference between true cryptographic irreversibility and practical irreversibility. A file corrupted by decayfmt is gone in any practical sense, but the process itself isn't mathematically one-way in the way that, say, a cryptographic hash function is. The stochastic nature of the corruption means that if you had multiple snapshots of the same file at different decay stages, you could potentially reconstruct the original by analyzing the pattern of changes.

How to Understand decayfmt's Broader Implications

• Recognize the DRM Pattern: Any system that tries to control data through the reader program rather than through cryptography bound to the data itself will fail once users control their own hardware and can modify or replace the reader.
• Understand the Diffusion Connection: The forward noise process in decayfmt is structurally identical to the noise schedule that diffusion models learn to reverse, making this a useful mental model for understanding how AI image generation actually works.
• Appreciate the Open-Source Vulnerability: When enforcement logic is shipped as open-source code under permissive licenses like MIT, the enforcement mechanism becomes trivially bypassable by anyone with basic programming knowledge.
• Consider the Prototype Cost: The fact that a playful, functional DRM-like system can be built in 200 lines of Rust and go viral on social media demonstrates how low the barrier to entry now is for prototyping content control schemes.

What makes decayfmt genuinely interesting isn't that it's useful; it's that it's a legible, miniature version of a problem that has plagued the technology industry for decades. By making the mechanism transparent and open-source, the creator has created a teaching tool that explains why software-based content protection fundamentally cannot work on hardware controlled by the user. That insight, wrapped in a playful package, is why a file format that deliberately corrupts itself has sparked serious technical conversation among thousands of developers.

" }