💬 Messaging

The message archive stores your conversations in the same database as everything else, in an open, platform-agnostic format — built so today it's WhatsApp and tomorrow Telegram, Signal, SMS or iMessage can join without changing the model.

How it's modeled

It follows the Matrix event model (the open messaging standard), adapted to SQLite under the chat_ prefix:

Table	What it stores
chat_rooms	each conversation (1:1 or group), with its platform and message count
chat_events	one event per row (message, photo, audio…): sender, a millisecond timestamp, msgtype (m.text, m.image…), and JSON content
chat_senders	each sender as its own entity, linkable to a person in the family tree

Because events are standard, one reader serves any platform and the data stays portable: it's never locked into any single app's proprietary format.

Where the messages come from

An ingester normalizes each source into those tables. For WhatsApp, two complementary corpora coexist without overwriting each other:

• iPhone backup (ChatStorage.sqlite, Apple's Core Data) — the recent history.
• .txt/.zip exports from earlier years — the older stretch the backup no longer holds.

The ingester is additive and idempotent: it never deletes a chat or a message, and re-running it never duplicates anything (every event has a stable identifier). Every write goes through the reversible snapshot layer.

What you see

• An index of every chat, with search and a monthly activity chart (sent vs. received).
• A per-conversation page with messaging-style bubbles, day separators, sender labels in group chats, and attached media (photos, audio, video, documents).

Media is served from your own server, never from a cloud.

The point-and-count rule

The assistant builds the infrastructure and counts (how many messages, from whom, when), but it never reads or classifies the content of your conversations. Reading is for you; the machine only indexes mechanically.

This is a read-only archive: queries and statistics, not a client for sending messages.