Structura.Wiki

Your conversation history, exported and then abandoned

Every major AI chat product lets you export your history — a ZIP file, downloaded once, then almost always left in Downloads forever. The export is real data, often months of thinking-out-loud, but it's locked inside a raw JSON structure never meant for a human to read directly, and there's no tool built to make it browsable. Nobody wants to upload months of private conversations to a third-party service just to read them comfortably.

Structura turns that export into a library: each conversation becomes a book, organized onto shelves, taggable with stickers. The interesting constraint is self-imposed — for a tool whose entire input is "my private conversations," a server in the request path isn't a minor privacy concern, it's a disqualifying one. So the product has no backend. Import, storage, browsing, search, export — all of it happens in the tab, in IndexedDB, and nowhere else.

Licensing follows the same logic: the code is source-available under FSL-1.1-ALv2, converting to Apache 2.0 after two years. Not MIT, because a source-available license still discourages a direct SaaS relaunch of the exact product during the window that matters most — but source-available regardless, because a tool asking to be trusted with your private conversations should let anyone verify the "nothing leaves the browser" claim by reading the code, not just by reading a promise.

What it must do — and under what conditions

FR	Import a ZIP export from ChatGPT, Claude, or DeepSeek. Detect which platform produced it automatically — no format picker. Render each conversation as a readable "book"; organize books onto shelves; tag with stickers; search across the library; export back out.
NFR	Zero network requests, at any point in the application lifecycle after the page has loaded — not "we don't log," but structurally incapable of phoning home. Must handle exports large enough to contain hundreds of conversations without freezing the UI thread.
Constraints	No backend is permitted, by requirement — not a cost-saving choice, an inversion of the usual NFR hierarchy where "add a server" is normally the easy answer. Three undocumented export formats, none with a public spec, all of which drift silently between platform releases.

One request, ever

Vercel serves the static build — HTML, JS, CSS. That's the entire role of the network in this system: deliver the app once. Everything after that page load is local — a Web Worker unzips and parses the export off the main thread, a detection layer fingerprints which platform produced it, an adapter normalizes it into a common shape, and Dexie writes the result into IndexedDB. No component in this diagram has a line pointing back to a server, because none exists to point to.

Four decisions that shaped the system

Digests of the choices that mattered. Each names what the decision cost — a trade-off you don't acknowledge is a trade-off you didn't see.

Books, shelves, stickers

Four Dexie tables hold the library: books (one per imported conversation — source platform, title, timestamps, and a normalized array of messages produced by whichever adapter claimed the file), shelves (user-defined collections), stickers (tags), and a join table linking books to both. The messages array is the payload every adapter converges on — regardless of whether the source used a flat list, like ChatGPT's, or a branching tree of edits and regenerations, the adapter's job is to resolve it down to the same linear shape the reader component expects.

Three formats, zero documentation

None of the three platforms publish an export schema. Reverse-engineering meant exporting real conversations from each, then reading the raw JSON by hand to find the shape. The formats turned out to disagree on the one thing that mattered most: how a conversation is structured at all. ChatGPT's export is a tree — every message has a parent pointer, because edits and regenerations create branches, and the "current" conversation is really one path through that tree that has to be walked and flattened. Claude's export is closer to a flat ordered list. DeepSeek's sits somewhere between the two, with its own vocabulary for the same concepts. A ConversationAdapter interface absorbs the difference: each adapter's only contract is to take its platform's raw shape in and hand back the same normalized message array, regardless of how different the walk was to get there.

Formats move under you

An undocumented format isn't a fixed target — it's a snapshot of whatever the platform happened to export the week you looked. A field renamed or nested one level differently in a later export doesn't throw a parse error; the content-fingerprint detector simply fails to recognize the file, or worse, a loosely-written check matches it to the wrong adapter and silently produces garbled output. The mitigation is defensive fingerprinting — checking for several structural markers together rather than one loose signal — plus keeping a real anonymized export from each platform as a permanent test fixture, so a platform-side format change shows up as a failing test instead of a support ticket.

The privacy claim was proven, not asserted

"Nothing leaves your browser" is the entire value proposition, so it's the one claim on this page that doesn't get to rest on code review alone. It was checked three separate ways, each catching a different failure mode:

If I rebuilt it

• The CSP header should have existed from the first commit, not been added as a verification afterthought. A structural guarantee is stronger when it's been true the whole time, not just true now.
• Each adapter's test fixture should be a contract, checked in CI against a fresh export whenever one of the source platforms ships an update — currently that check is manual and triggered by noticing something looks wrong.
• An in-browser export-your-library-as-a-file backup prompt, surfaced periodically. With no server, "clear site data" is unrecoverable, and the product doesn't currently warn anyone about that trade-off at the moment it matters.
• The two-year FSL conversion window is a decision I'd want to revisit closer to the deadline, not one to treat as settled — the right call depends on how the project's usage looks by then.