AnubisDB

Inspect, export and clear every app's on-device data

Overview

AnubisDB is the on-device data vault and explorer for the kimtos app suite. Every other app stashes its data in one shared browser database — the kimtos IndexedDB — and AnubisDB is the single console over it: browse what each app has saved on this device, back it up, or clear it. It is part of the kimtos new-tab app suite.

Everything is fully on-device. There is no backend, no account, and no network. AnubisDB reads the same local database the other apps write to, and nothing it shows you ever leaves the machine. Exports are files you download; imports are files you pick.

Highlights

• Browse every app's local data — a left-hand list of the apps that have stored anything, each showing its item count and size. Pick one to see its data grouped into partitions.
• Three kinds of storage — each app's data is grouped as records (collections), files (media blobs), and settings (key/value caches), named and coloured after the owning app.
• Readable record inspector — expand a record to read it in a Formatted view (typed values, smart timestamps, links, image thumbnails, collapsible nesting) or flip to Raw JSON with one click; copy either.
• Download individual files — each stored media blob can be downloaded on its own from its row.
• Per-app and full backups — export one app as <id>.json, or the whole database as kimtos-backup.json, then import either back.
• Clear with undo — delete one app's data or wipe everything; a brief toast offers Undo that restores exactly what was removed.
• Live auto-refresh — the view re-scans when any app changes the database (or when the tab regains focus), so what you see stays current without flicker.

What it shows

AnubisDB attributes data to apps automatically from the storage naming convention, so a new app's data appears — named and grouped — with no changes to AnubisDB. Alongside the dock apps you may see a few system owners:

• Settings & caches (system) — key/value data that belongs to no single dock app.
• Wallpapers — stored background images.
• Unmapped data — anything whose storage name does not follow the convention; this is the signal that a partition was named unexpectedly.

Privacy model

AnubisDB only ever reads and writes local browser storage:

• It reads the three fixed stores of the one kimtos IndexedDB — records, blobs, and kv — directly, and never opens any other database.
• Exports are plain JSON files you download; imports are JSON files you choose.
• Nothing is uploaded, and there are no analytics or third-party calls.

Because a backup is a faithful, self-contained dump (media files are inlined as data URLs), your data is portable and a restore reproduces exactly what was exported.

Getting Started

Open AnubisDB from the dock. It scans the local database and shows a toolbar with running totals, a list of apps on the left, and the selected app's data on the right. If nothing has been stored yet, it says so — use any app and your data will show up here.

The toolbar

The top bar shows the total size, item count, and number of apps stored on this device, plus four actions:

• Refresh — re-scan the database by hand (it also auto-refreshes; see below).
• Import — restore a kimtos or AnubisDB JSON file you previously exported.
• Export all — download a full backup as kimtos-backup.json.
• Clear all — erase every app's stored data (with an Undo).

When the database is empty, everything except Refresh is disabled.

Browsing an app's data

The left column lists each app that has stored something, with its item count and size. Click one to inspect it on the right. The detail pane shows the app, its totals, per-app Export and Clear actions, and its data grouped into partitions.

Each partition is a collapsible row tagged by kind:

• records — a collection of structured records.
• files — stored media blobs.
• settings — the app's key/value settings and caches, collapsed into one row.

Click a partition header to expand it and load its items.

Inspecting a record

Inside a records or settings partition, expand an item to see its value. It opens in the Formatted view by default — a readable field-by-field layout that:

• shows a Title Case label for each field,
• formats likely timestamps as real dates (with a relative "3d ago"),
• turns URLs into links and data: image values into thumbnails,
• renders booleans as Yes/No chips and clamps very long text behind a show all,
• lets you collapse nested objects and arrays.

Use the Raw JSON toggle above the value to switch to the exact stored JSON, and the copy button to copy it. Long settings values are truncated in the raw view for readability.

Downloading a file

Inside a files partition, each row shows the blob's key, type, and size, with a download button to save that single file to disk.

Exporting and importing

• Export all downloads the entire database as kimtos-backup.json.
• Export (in an app's detail header) downloads just that app as <id>.json, a self-contained dump with its media inlined.
• Import accepts either kind of file — a full kimtos backup or a per-app AnubisDB dump — and merges it back in. A file that is neither is rejected with a message.

Clearing data (with undo)

• Clear (in an app's header) deletes that one app's data after a confirm that spells out how many items and how much space it frees.
• Clear all erases everything across every app after a confirm.

Either way, a toast appears with an Undo action that restores exactly what was removed — so a mistaken clear is recoverable for a few seconds. Export a backup first if you are unsure.

Auto-refresh

AnubisDB keeps itself current. It re-scans (debounced) whenever any app writes to the database, and again when the tab regains focus — which also catches changes made in other tabs. Re-renders only happen when something material actually changed, so your selection and scroll position are preserved and the view does not flicker.

Working with the assistant

AnubisDB exposes read-only tools to the HomeAI assistant: it can summarise everything stored (db_summary), list one app's partitions (list_app_data), and fetch a single record as JSON (get_record). Destructive actions stay a live user gesture — the assistant can inspect your storage but can never erase it.

Architecture

AnubisDB is the DB inspector, not a per-collection CRUD app: it reads the one shared kimtos IndexedDB directly, groups every partition under the app that owns it, and offers per-app and global export, import, and clear. Everything is local. The code lives in extension/src/apps/anubisdb/.

Modules

File	Role
meta.ts	The app manifest — id, name, accent (#c9a34a), order, and App Store marketing copy.
index.ts	The app descriptor and UI — the toolbar totals, the app list, the detail pane with expandable partitions and rows, downloads, and the export/import/clear actions (each with a confirm and Undo). Also declares the read-only HomeAI tools.
introspect.ts	The read/export/import/clear layer over the database. scan() walks the three stores and builds the grouped snapshot; partitionItems() loads one partition's items; exportApp/importData/clearApp/clearAll handle backups and deletion.
registry.ts	Ownership resolution. ownerOf(name) maps a records collection, blob namespace, or kv key to the owning app id; app labels/colours are derived from every app's meta.ts, plus system buckets and an "Unmapped data" fallback.
prettyView.ts	The human-readable record inspector. renderJson() / renderValue() turn stored JSON into a readable field view — typed values, smart timestamps, links, image thumbnails, and collapsible nesting — behind the "Formatted view" default.
lib/idb.ts · lib/dataStore.ts	The shared low-level IndexedDB access and the suite's data-store helpers used for reads, blob/kv deletes, and full-backup export/import.

How it reads the store

scan() reads all records, plus the keys of blobs and kv, from the single kimtos database. Each row is grouped into a bucket keyed by kind and partition; ownerOf resolves which app the partition belongs to, and the buckets are folded into per-app nodes carrying counts and sizes. Records are measured by their JSON byte length; a blob is measured by its cheap .size (its bytes are never loaded to do so). Apps are sorted with system and unmapped owners last.

Resolving ownership

registry.ts derives ownership from the storage naming convention rather than a hand-maintained table:

• history:<app> keys (and history:<app>/<uid> blobs) map straight to that app.
• A small legacy table covers a few early collections and prefixes whose names predate the convention (e.g. todos → tasks, pdf: → pdflib).
• Otherwise the leading segment (before -, :, or /) is taken as the owning app id — thoth-chunks and thoth:hashes both resolve to thoth. If that id is a known app, it wins.
• Anything still unresolved is grouped under Unmapped data; unprefixed kv keys default to the system bucket.

Because labels and accents come from each app's own meta.ts, a new app's data is named, coloured, and grouped automatically — no edit to AnubisDB.

Export, import, and clear

• Export builds a self-contained per-app dump (format: 'anubisdb-app') with records copied verbatim, blobs inlined as data URLs, and kv values included. Export all delegates to the data store's full-backup export (kimtos-data).
• Import accepts either format: a full backup is restored through the data store; a per-app dump is written back with idb.put for each record, blob (data URL → Blob), and kv value. Any other file is rejected.
• Clear first captures a backup (via the same export path) for undo, then deletes the app's records, blobs, and kv entries; Clear all captures a full backup and empties all three stores. The captured backup is what the Undo toast passes straight back to import.

Auto-refresh

The UI subscribes to the data store's change signal (debounced ~400 ms to collapse bursts like a bulk clear) and to tab focus/visibility, then re-scans. A lightweight fingerprint of the snapshot (per-app and per-partition counts and sizes) is compared before redrawing, so the DOM is rebuilt only when something material changed — preserving selection and scroll and avoiding flicker.