DEV Community: showjihyun

Article - 1 How Figma stores your design files (and how to read them offline)

showjihyun — Fri, 15 May 2026 13:08:59 +0000

A 5-minute tour from the bytes on disk to the 35,660-node tree your designer never sees.

You hit File → Save as .fig in Figma. You drop the result on your desktop. Open it in your text editor and you get… a wall of garbage. Not even a recognizable header.

What's actually in there?

I spent a few weeks taking one apart, byte by byte, and built an open-source parser around it (figma-reverse — TypeScript, MIT, no Figma API). This post is the tour I wish someone had handed me when I started.

TL;DR — A .fig file is a ZIP. Inside it lives canvas.fig, the actual binary, in a format called fig-kiwi. Decode it and you get 568 type definitions plus a flat array of 35,660 nodes. Walk the parents and you get the tree your designer was looking at.

Five layers, each with its own format:

.fig (ZIP)
  └── canvas.fig (fig-kiwi)
       └── chunks[0] = compressed schema
       └── chunks[1] = compressed message
                       (35,660 flat nodes)
                          ↓ link by parent GUID
                       Tree of pages → frames → leaves

Let's walk down.

Layer 1 — The outer file is a ZIP

The first 4 bytes give it away:

$ xxd -l 4 design.fig
00000000: 504b 0304                                PK..

50 4B 03 04 is the PKZIP local file header — every ZIP starts with it. Figma's .fig is, prosaically, a ZIP archive in STORE mode (no compression) with four entries:

design.fig (ZIP STORE)
├── canvas.fig          ← the real binary, more on this below
├── meta.json           ← file_name, background_color, exported_at
├── thumbnail.png       ← small preview
└── images/
    ├── <sha1-hash-1>   ← raw bytes, no extension
    ├── <sha1-hash-2>
    └── …

A surprise: the images have no file extension. They're keyed by SHA-1 hash because the same image (a PNG icon, say) might be referenced 50 times across your design. Deduplication for free. To recover the type, you sniff the magic byte: 89 50 4E 47 is PNG, FF D8 FF is JPEG, etc.

So far, nothing exotic. Standard ZIP, standard PNG.

Layer 2 — `canvas.fig` is in fig-kiwi format

Open canvas.fig and you see an 8-byte ASCII string at offset 0:

00000000: 6669 672d 6b69 7769 6a00 0000 ...        fig-kiwij....

fig-kiwi is the magic. After it comes a 4-byte little-endian uint32 — the format version (0x6a = 106 in modern exports). Then come the chunks.

The structure is dead simple — like TLV without the T:

[8 bytes  ] "fig-kiwi" magic
[4 bytes  ] version (LE uint32)              ← 106
[4 bytes  ] chunk[0].size (LE uint32)
[N bytes  ] chunk[0].data
[4 bytes  ] chunk[1].size
[N bytes  ] chunk[1].data

Just two chunks. You'd think the first would be a header and the second the payload. Half right.

Layer 3 — Two compressed blocks, two algorithms

This is where it got weird.

I assumed both chunks were compressed the same way. The existing OSS fig-kiwi npm package assumes deflate-raw. I plugged it in, decoded chunk 0 — got something. Decoded chunk 1 — silent garbage.

Looked at the magic bytes:

$ xxd -l 4 chunk0.bin   # chunk 0
00000000: 78 da xx xx                           x...     # zlib's standard prefix

$ xxd -l 4 chunk1.bin   # chunk 1
00000000: 28 b5 2f fd                           (./.    # zstd's magic

Chunk 1 is zstd. Not deflate. Not gzip. Facebook's modern zstd. Most existing .fig parsers don't know.

I'll come back to why in the next article, but for now: auto-detect the algorithm from the magic byte and fork. In figma-reverse:

function detectCompression(buf: Uint8Array): 'zstd' | 'deflate-zlib' | 'deflate-raw' {
  if (startsWith(buf, [0x28, 0xB5, 0x2F, 0xFD])) return 'zstd';
  if (buf[0] === 0x78) return 'deflate-zlib';
  return 'deflate-raw';
}

After decompression, chunk 0 is 64 KB of binary type definitions. Chunk 1 is 20 MB of binary message data, encoded against those definitions.

Layer 4 — Kiwi: a self-describing binary schema

Kiwi is a binary serialization format by Evan Wallace (one of Figma's founders). It's like Protocol Buffers, but the schema definitions ship inside the same stream as the data — perfect for clients that get pushed schema updates.

Decoded, chunk 0 contains 568 type definitions:

NODE_CHANGES { nodeChanges: NodeChange[], blobs: Bytes[], ... }
NodeChange   { guid: GUID, type: NodeType, ... }
GUID         { sessionID: uint32, localID: uint32 }
Vector2      { x: float, y: float }
Transform    { m00, m01, m02, m10, m11, m12: float }
Paint        { type: PaintType, color: Color, opacity: float, ... }
... 562 more

In TypeScript, decoding a .fig is three lines once you've got the schema and data buffers:

const schema   = kiwi.decodeBinarySchema(schemaBytes);   // 568 type defs
const compiled = kiwi.compileSchema(schema);             // generate decoder class
const message  = compiled.decodeMessage(dataBytes);      // root: NODE_CHANGES

message is now a JavaScript object. Specifically, it has a nodeChanges property — an array. And here's the next surprise.

Layer 5 — The "tree" is a flat array

message.nodeChanges is flat. For my test fixture (a real, mid-sized Figma file): 35,660 entries. Not a tree. A list.

Each entry has a parentIndex.guid pointing at another node and a parentIndex.position string. Reconstruction is two passes:

// Pass 1: index every node by GUID
const allNodes = new Map();
for (const nc of message.nodeChanges) {
  allNodes.set(`${nc.guid.sessionID}:${nc.guid.localID}`, {
    ...nc, children: []
  });
}

// Pass 2: link children → parents, then sort siblings
let document = null;
for (const node of allNodes.values()) {
  const parent = allNodes.get(`${node.parentGuid.sessionID}:${node.parentGuid.localID}`);
  if (parent) parent.children.push(node);
  else if (node.type === 'DOCUMENT') document = node;
}

// Sort by parentIndex.position string (Figma's fractional indexing)
function sortChildren(n) {
  n.children.sort((a, b) => a.position < b.position ? -1 : 1);
  for (const c of n.children) sortChildren(c);
}
sortChildren(document);

Two oddities here:

1. Why a flat array? Because Figma's wire format is built for streaming edits. Every change a designer makes is a NodeChange record appended to a multiplayer message. The "saved file" is just the materialized end state of that stream.

2. The sort key is a string. parentIndex.position looks like '~)Wxs', '~)Wxs#', '~)Wxs#0'. That's fractional indexing — a string-based ordering that lets two clients insert between any two siblings without conflict. It's a CRDT trick, and it shows up because Figma is collaborative-first.

After sorting you finally have a tree:

DOCUMENT
├── CANVAS "Page 1"
│   ├── FRAME "Header"
│   │   ├── TEXT "logo"
│   │   └── …
│   └── FRAME "Body"
│       └── …
└── CANVAS "Page 2"
    └── …

The shape every designer recognizes. Six pages, hundreds of frames, thousands of leaves.

What you can do with this

Once you have the tree in memory, you can:

Export to JSON — JSON.stringify(documentTree) and you're done. Caveat: Uint8Array and BigInt need special encoding (see article 3).
Generate Pencil .pen — Pencil.dev is an OSS Figma alternative; their .pen format is JSON-shaped, and the conversion is mostly a 1:1 type mapping plus visibility composition. figma-reverse ships a pen-export subcommand that does this in ~1.8 s for 35K nodes.
Build a RAG index — flatten to per-page JSON (~140 KB per page in the sample), embed each page or each frame, and you can ask questions like "where does this button get its primary color from?" with grounded retrieval.
Edit and re-encode — change a value in JSON, then re-pack via the kiwi codec → ZIP STORE → and you have a new .fig Figma will open. (Article 3 has the details on what makes this round-trip-safe vs lossy.)

Try it yourself

git clone https://github.com/showjihyun/figmatojson.git
cd figmatojson && npm install
npx tsx src/cli.ts extract docs/bvp.fig
cat output/bvp/verification_report.md

The repo has 162 unit tests covering every stage and a 5-layer harness (docs/HARNESS.md) that proves the round-trip equality. There's a single-file bilingual developer guide at docs/dev-guide.html with eight mermaid diagrams.

Up next

This was the what. Article 2 — The two-tiered compression mystery in Figma's .fig format digs into why one of the two chunks is zstd and the other is deflate. (Hint: it's not a mistake.)

Article 3 — Building a round-trip-safe parser covers what it takes to go back: from a JSON tree to a byte-identical .fig, and what Uint8Array / NaN / BigInt do to your JSON.stringify.

⭐ If this saved you a Figma API headache or a few hours of binary archaeology, give the repo a star. It's how I'll know whether to keep covering edge cases.

"Memory Is the Unsolved Problem of AI Agents — Here's Why Everyone's Getting It Wrong"

showjihyun — Wed, 15 Apr 2026 13:27:42 +0000

Every AI coding agent on the market ships with amnesia by design.

Claude Code starts each session with a blank context window. Cursor loses your architecture when you close the tab. The most capable models ever built can't recall what you said 10 minutes ago once the context fills up.

The industry's answer? A markdown file loaded at startup.

I spent the past month studying how agent memory actually works across the major systems — Claude Code's recently exposed internals, Mem0's vector store, Zep's temporal graph, Letta's OS-inspired tiers. The benchmarks are public. The architectures are documented. And every one of them is solving the wrong problem.

Three paradigms, three failure modes

1. File-based: Claude Code

Claude Code reads CLAUDE.md from your project root at session start. The entire file goes into the context window. No vector DB. No embeddings. No search.

Since v2.1.59, "auto memory" writes notes to ~/.claude/projects/<project>/memory/ — things like build commands, debugging patterns, style preferences. Still markdown. Still loaded wholesale. MEMORY.md has a hard cap at 200 lines. Anything beyond gets silently truncated.

This is intentionally simple. And for small projects it works. The failure mode is obvious: no selective retrieval. A 200-line cap on a monorepo with years of decisions means most knowledge is discarded. You either load everything or nothing.

2. Vector search: Mem0 and Zep

Mem0 (48K+ GitHub stars) decomposes interactions into facts and preferences, stores them as embeddings, and retrieves via semantic similarity. Zep builds a temporal knowledge graph — entities as nodes, relationships as edges, with timestamps tracking when facts were valid.

The benchmark data is revealing:

System	LongMemEval	Memory per conversation	Architecture
Mem0	49.0%	~1,764 tokens	Vector + Graph + KV
Zep	63.8%	~600,000 tokens	Temporal KG + Vector
Letta	~83.2%	Dynamic	Tiered (Core/Recall/Archival)

Mem0 fails to recall the right information more than half the time. Zep is 15 points better — but uses 340x more memory per conversation. The Zep team disputes the Mem0 paper's configuration, claiming a corrected score of 75.1%. Even so, the tradeoff is steep.

![Scatter plot showing accuracy vs memory footprint: Mem0 at 49% with minimal tokens, Zep at 64% with 600K tokens, Letta at 83% in between]

The deeper problem: both assume memory = retrieval. Store everything, search when needed. But retrieval accuracy is only useful if you're retrieving at the right moment. Neither system has a mechanism for deciding "does this agent need memory at all for this task?"

3. OS metaphor: Letta (MemGPT)

Letta models memory like an operating system. The context window is RAM. External storage is disk. The agent pages information in and out via explicit tool calls: core_memory_append, archival_memory_search, conversation_search.

On benchmarks, Letta leads the open-source field at ~83.2%. The agent makes nuanced decisions about what to keep in its working set. Architecturally, this is the most ambitious approach.

The cost: every memory operation burns inference tokens. The agent reasons about what to store, what to retrieve, how to organize — and that overhead compounds. Simple tasks get expensive because the agent spends a significant portion of its token budget on memory management rather than on the actual task.

The real problem nobody's solving: forgetting

Ebbinghaus mapped the human forgetting curve in 1885. We don't remember everything. We forget most things. What survives is what got reinforced — through repetition, emotional weight, or retrieval practice.

AI agents have no forgetting strategy. They either hoard everything (vector stores growing without bound) or lose everything (session boundaries that wipe the slate). There's no equivalent of "this decision from 3 months ago is probably stale" or "this debugging pattern surfaced 4 times — promote it to permanent storage."

![Chart comparing human forgetting curve with agent memory patterns: session-based drops to zero, vector stores grow unbounded, active curation follows a healthy decay]

Claude Code's source, briefly exposed via an npm packaging error on March 31, contains a hint of the right direction. A module called DreamTask runs during idle time — consolidating memories, merging duplicates, archiving stale entries. The codebase literally calls it "dreaming."

But it's primitive. A separate module memoryAge.ts calculates memory age and appends a text warning: "This memory is 47 days old. Claims may be outdated." Just a string appended to the content. The system doesn't reduce the memory's weight, doesn't trigger re-verification, doesn't decay its relevance score. The warning exists. The system doesn't act on it.

What's needed isn't better storage or retrieval. It's active curation — continuous evaluation of what's worth keeping, what should decay, and what should be promoted based on actual usage patterns.

Where it compounds: multi-agent memory

Everything above assumes one agent, one memory. Now multiply.

In multi-agent setups — Claude Code's subagents, CrewAI's role-based teams, AutoGen's collaborative agents — memory becomes a coordination problem.

A concrete scenario: Agent A decides to use the repository pattern for data access. Agent B, working on a separate module, implements raw SQL queries. Agent C reviews both and sees contradictory patterns. None of them know about the others' decisions because each agent's memory is private.

Claude Code's current solution: all agents read the same CLAUDE.md. When one writes, others pick it up on their next file read. This handles 2-3 agents. At 20+ agents making concurrent decisions, you get write conflicts, stale reads, and contradictory entries that nobody reconciles.

Research in agent-based social simulation — Stanford's Generative Agents, Tsinghua's AgentSociety, CAMEL-AI's OASIS — has been hitting these problems at scale for years. When hundreds of agents interact over time, questions emerge that single-agent memory never encounters:

Social reinforcement — If 50 agents independently store the same fact, is it more durable or just more popular?

Memory conflict — When two agents hold contradictory memories of the same event, what resolves the disagreement?

Information decay — When does a group "forget" something? When every individual forgets, or when it stops being referenced?

These aren't academic curiosities. They're the exact problems that any production multi-agent system will face once it scales past a handful of agents.

A hypothesis, not a solution

I don't have a working system to show. What I have is a hypothesis after studying all of these:

Memory in multi-agent systems is a coordination problem, not a storage problem.

Claude Code is right about simplicity. Mem0 is right about searchability. Letta is right about agent autonomy. None of them address the coordination dimension — the fact that agents need to share, negotiate, and reconcile memories, not just store and retrieve them privately.

The components that seem necessary:

Tiered personal memory — episodic (what happened) + semantic (what I know), with explicit promotion and demotion rules between tiers. Letta has the right shape here.

Shared state protocol — not a shared file, but a structured mechanism for propagating decisions across agents. Something closer to a distributed log than a wiki.

Active forgetting — relevance decay weighted by access frequency, age, and cross-agent reinforcement. Things that multiple agents reference stay. Things only one agent cares about fade.

Conflict as data — when memories contradict, maintain the disagreement as a first-class object rather than silently picking a winner.

The Meta-Harness paper (Stanford & MIT, March 2026) demonstrated that harness design alone produces a 6x performance gap on the same underlying model. Memory is arguably the highest-leverage harness component that remains wide open. The current state of the art is either "load a markdown file" or "search a vector store and hope for 49% accuracy."

There's a lot of room to do better. The agent that wins won't be the one that remembers the most. It'll be the one that knows what to forget.

What's your setup for agent memory? If you've found something that actually works across sessions — or something that failed spectacularly — I'd like to hear about it in the comments.

Prophet: We Built a Wind Tunnel for Marketing Campaigns

showjihyun — Mon, 13 Apr 2026 16:11:29 +0000

Focus groups lie. A/B tests are too late. Brand-lift studies take 6 weeks, cost $50K, and tell you nothing about why a message failed.

So we built Prophet — an open-source platform that simulates how your message spreads through 10,000 AI agents organized into the communities you actually care about.

💡 Think of it as a wind tunnel, but for campaigns instead of airplanes.

🔄 The Core Loop

⚙️ 1. Set up Message · communities · dials	▶️ 2. Run 10K agents · real-time 3D graph	⚡ 3. Intervene Pause · inject crisis · replay
📊 4. Analyze Adoption curves · sentiment	🔍 5. Drill in Read actual conversation threads	⚖️ 6. Compare Clone · change variable · diff

🧠 What's Under the Hood

Component	Detail
Agent Architecture	6-layer cognitive stack: `perception → memory → emotion → cognition → decision → influence`
Network Model	Hybrid Watts-Strogatz + Barabási-Albert with validated clustering & modularity
Opinion Dynamics	Deffuant bounded-confidence model for endogenous polarization
Emergent Detectors	Viral cascade · Slow adoption · Polarization · Collapse · Echo chamber
Cost Control	3-tier LLM inference — full 10K-agent run under $5
Uncertainty	Monte Carlo sweep with P5 / P50 / P95 quantification

🚀 Get Started

git clone https://github.com/showjihyun/Prophet
cd Prophet
npm install
# No API keys required to start
npm run dev

✅ Reproducibility Guarantee

Every claim in the README has per-step JSON you can audit.

Every equation traces back to a published paper.

Everything is reproducible. Runs on a laptop.

🤝 We're Looking for Contributors

Especially:

🐛 Bug reports
🧪 Test cases & validation studies
💡 New use cases

If you're simulating something interesting, we want to hear about it.

showjihyun / Prophet

Prophet

🔮 Prophet

The wind tunnel for marketing campaigns

Test your campaign on 10,000 AI agents before you spend a dollar on the launch.

🚀 Quick Start · ✨ Features · 🎯 Use Cases · 📊 Comparison · 📖 Docs · 🤝 Contributing

git clone https://github.com/showjihyun/prophet.git
cd prophet && docker compose up -d
open http://localhost:5173

That's it. 5 minutes from clone to your first simulation. No API keys required to start — Prophet runs fully locally on a laptop.

💡 Why Prophet?

Focus groups lie — 10 humans in a room cannot tell you how a message spreads through a community. A/B tests are too late — by the time you have data, you're already paying for the launch. Brand-lift studies take 6 weeks, cost $50K, and tell you nothing about why a message failed.

Every discipline that ships things at scale — aerospace, civil engineering, software — gets to simulate…

View on GitHub

Hi Guys. First Greetings

showjihyun — Sat, 04 Apr 2026 13:13:55 +0000

Hi~ Nice to Meet you guys!!