Building a Chat Export Analyzer: Privacy, Timelines, and Heatmaps

Chat exports preserve years of conversation, but they are hard to explore as plain files. I built LoreSync to turn supported WhatsApp and Discord exports into timelines, activity heatmaps, participant summaries, and other views people can inspect.

The problem

A long export contains a lot of messages, but finding a pattern means scrolling through a large amount of text. LoreSync gives people a visual way to explore when activity happened and how participation is distributed. The challenge is to make those views useful without suggesting that a chart knows more than the exported data can tell us.

The current import scope is deliberately specific: WhatsApp plain-text .txt exports and Discord .json exports up to 25 MB. Stating that scope gives the feature a clear contract. It tells people what they can try today and avoids implying that every chat format will work.

Different views, one conversation

Each view answers a different question. A timeline helps someone look across the life of a conversation. An activity heatmap makes recurring periods easier to spot. Participant summaries compare how messages are distributed among the people represented in the export.

Those views are only useful if they remain consistent with the same imported conversation. A count should mean the same thing wherever it appears, and a visual pattern should be explainable from the messages that produced it. The product work is not just drawing charts; it is choosing what each view represents and keeping the labels honest about that meaning.

That also means resisting the temptation to turn activity into a judgement. LoreSync describes patterns in an export. It does not score sentiment or decide what a relationship means. More interpretation would not automatically make the software more helpful.

Privacy shapes the data flow

One of the product decisions was to make browser-based analysis the default. Parsing and analysis happen in the browser, and the original export stays there. A person can explore the supported views without first sending the raw file to a server.

There is a trade-off: an analysis kept in one browser is not automatically available on another device. LoreSync offers an optional account-backed archive for people who choose it. That path requires signing in and confirming; the archive stores parsed messages and analysis rather than the original export.

Thinking in terms of data paths made “privacy” more concrete for me. The useful questions are: what file does the person select, where does parsing happen, what stays on the device, and what changes only after the person opts into an account feature? The product explanation should make those differences understandable.

Clear boundaries are part of the product

LoreSync is in early access. It supports specific export formats and a current file-size limit; those are real product boundaries, not footnotes. The app also summarizes observable activity rather than claiming to infer intent or emotion.

Being clear about scope helps people judge whether the tool fits their data and expectations. It also gives me a more useful way to plan engineering work: improve the import and analysis experience within a defined contract, then expand that contract only when the product can support it reliably.

What I learned

Building LoreSync has reinforced that software engineering includes decisions about meaning and trust, not only implementation. The different views need to be understandable, the data flow needs to be explicit, and the output needs to stay within what the data supports.

I’m continuing to improve the product while keeping its current limits visible. You can try LoreSync, read the project case study, or explore the source repository.