What I Was Trying to Do
Claude web (the browser version) and Claude Code (the terminal version). These two can't communicate directly. They live in separate sessions, separate worlds.
But I wanted to make them work together.
The communication channel: Gmail. Code has access to the Gmail API. The web version sends an email, and Code reads it. And vice versa.
"Let's compress it, then."—And so began a five-version journey of improvement.
v1: Starting with Plain gzip
The first approach was textbook: gzip compression with base64 encoding.
58% reduction. Not bad. But 15,720 characters was still too large. Pasting it into a Gmail body left almost no room for other instructions.
v2: The Custom Dictionary Idea
HTML is full of repetition. Patterns like background: linear-gradient( appear dozens of times.
background: linear-gradient( → §20border-radius: → §31box-shadow: → §42
Minify HTML → dictionary substitution → gzip.
About 1,500 fewer characters. Progress, for sure. But still in the 14,000 range. Not a fundamental solution.
v3: Pushing Ultra-Minify to the Limit
I pushed minification to the extreme—adding CSS structural patterns to the dictionary and minimizing the pre-compression text as much as possible.
This is where I hit a wall. gzip has a fundamental compression ceiling. No matter how much preprocessing you do, there's a point beyond which it won't shrink further.
"What if I stop trying to send it all in one message?"—A shift in thinking.
v4: Split Sending and Diff Mode
Split into 2 messages
Each email under 10KB, bypassing the size limit. The "can't send" problem was solved.
The idea of delta transmission
No need to send the full text every time. Just the differences from last time should be enough.
…but there was a catch
Computing diffs on minified text produces large deltas. Without line breaks, everything collapses into a single line. Even a one-character change becomes a "whole line changed."
Minification and diffing turned out to be a bad combination.
v5: Reversing the Order Achieved 98% Reduction
The lesson from v4's failure was simple.
Just diff first.
Compute the diff on the original text—line breaks, whitespace, and all—before any processing. Even in 37,668 characters of HTML, if only 3 sections changed, the line-level diff is tiny.
{"changes": [
{"line": 142, "old": "color: #ff6600;", "new": "color: #ff8800;"},
{"line": 287, "old": "padding: 20px;", "new": "padding: 24px;"},
{"line": 503, "old": "display: none;", "new": "display: block;"}
]}
Compress those few lines of JSON with gzip, and—
The Full Evolution
| Version | Method | Characters | Reduction |
|---|---|---|---|
| v1 | gzip + base64 | 15,720 | -58% |
| v2 | minify + dictionary + gz | 14,244 | -62% |
| v3 | ultra-minify + dictionary | 13,832 | -63% |
| v4 | split + diff | 11,366 | -70% |
| v5 | diff → minify → gz | 245 | -99.3% |
Why 98% Reduction Was Possible
Think about game updates. Nobody downloads an entire 10GB game every time there's a patch. Only the changed portions are distributed as a delta update.
The same principle applies to text. The critical factor, however, was when you compute the diff.
Post-processed (minified) text has no line breaks, making it unsuitable for diff detection. Pre-processed text—in its human-readable state—can be cleanly diffed line by line.
"Compress then diff" vs. "diff then compress."
That single reversal in order made the difference between 11,366 characters and 245.
Toward an Era Where AI-to-AI Communication Is the Norm
This compression protocol was born to solve a fairly niche problem: exchanging files between two AI instances.
But think about it—scenarios where AI agents communicate with each other will only increase from here. One AI creates something, another receives and processes it. When that happens, "how to pass data efficiently" becomes an unavoidable challenge.
ROCK PROTOCOL is a small protocol born from an indie development project, but I believe the underlying concept of "delta compression for AI-to-AI communication" has much broader potential.
Reducing 37,668 characters to 245 isn't just a compression story. It's a story about how identifying "what actually needs to be sent" turned out to be the greatest optimization of all.
Keiji Rokuta Based in Fukuoka, Japan—working as a private tutor while developing AI-powered tools.
Still managing tutor attendance manually?
Discover Kagemusha System