---
title: Supermail Archive Insights
---
# Supermail Archive Insights

## What it is

**Archive Insights** tracks the emails you archive in Supermail — **whether you opened them first,
and how long you spent** — and surfaces the senders and subject lines you keep archiving
(especially the ones you never open) — the mail you are effectively filtering by hand, and could
turn into a real auto-archive [Filter](supermail.md#filters). It is the passive, behavioural
counterpart to Supermail's rule-based Filters and its AI-powered
[AI Filtering](supermail-ai-filtering.md): those act on incoming mail; this one watches how you
actually triage and points out the patterns.

On by default, with three switches in Supermail **Settings → Inbox → Archive Insights** — the master
tracking switch, the filter-nudge switch, and a "track time spent per email" (dwell) switch. All
data stays on the device — no backend, no cost.

## Where to find it

Inside Supermail's own **Settings → Inbox → Archive Insights**, which holds the master switch and its two companions.

## How it behaves

### How it works

- **One capture point.** Every archive gesture (list, swipe, bulk, in-thread) funnels through
  `inbox-store.archiveThreads`; each archive is recorded tagged with whether the thread had been
  opened (`wasRead`). Automated filter-archives take a different code path (`api.archiveThreads`
  directly) and are never miscounted.
- **Time spent (dwell).** A small order-independent open-tracker records how long a thread was
  open; when you archive the thread you were reading, the event carries that duration (capped to
  bound idle-tab inflation), so quick-glance-then-archive senders stand out.
- **Undo-safe + off the hot path.** Events are buffered in memory and flushed to IndexedDB only
  after the ~10s undo window, so undoing an archive drops them before they persist; capture is
  error-isolated and never blocks or affects the archive itself.
- **Grouped for you.** A pure aggregator groups events by sender, sender domain, and a normalized
  subject (folding `Re:`/`Fwd:` and templated tails), with counts, a date range, the
  opened-vs-never-opened split, and the average time-open. The view filters between All / Never
  opened / Opened-then-archived.
- **One-click filter.** Each row — and the nudge — opens the Filter editor pre-seeded with an
  "auto-archive mail like this" rule for you to confirm (never a silent save).
- **Proactive nudge.** Keyed on the never-opened signal only: after you archive-WITHOUT-opening
  from the same sender a few times, a dismissible, rate-limited toast offers to create that filter
  on the spot (opened-then-archived doesn't push it).
- **Private + bounded + encrypted.** Sender/subject data is device-local and **encrypted at rest**
  (AMC's safeStorage keyring via a desktop-only, domain-tagged bridge that can decrypt only its OWN
  data — never another secret), retained long-term (~10 years, up to a generous row cap) so it's
  banked for future analysis, logged only through the PII-redaction logger, and a "Clear history"
  action wipes it.

Access the view at `/archive-insights` — from the command palette ("Archive Insights") or the
Settings launcher. Code + tested invariants:
`src/plugins/supermail/ui/src/features/archive-insights/` (see its `README.md`).

### Privacy

The store + nudge state are scoped **per signed-in account** (`archiveDbNameFor(currentIdentity())`),
so separate people sharing one machine profile never share a store; a one-time, verified,
non-destructive migration folds any legacy unscoped data into the current account. Everything is
device-local and never sent to a server. The sensitive sender/subject fields are also **encrypted at
rest** with the OS keyring — reusing AMC's `credential-encryption` engine through a scoped,
domain-tagged (`AIV1|`) renderer→main bridge that can decrypt only its own data, so it can never be an
oracle for another AMC secret. Invariants:
[supermail-archive-crypto-contract.md](../../.claude/memory/contracts/supermail-archive-crypto-contract.md).

### Known limitations

A row written while the OS keyring is momentarily unavailable is stored in plaintext until the
one-time upgrade re-encrypts it on a later load; a row that can no longer be decrypted (the profile's
keyring changed, or the store was copied to another machine) is dropped from the view — the at-rest
property means unreadable ciphertext stays unreadable, never surfaced as an error.

## Related

The AI Digest turns this data into concrete cleanup suggestions; Supermail AI Filtering is the rule-driven counterpart that acts on mail as it arrives.