imessage: backfill display names from vCard contacts

[bjabes]

Summary

iMessage-imported users showed up as raw phone numbers / emails because chat.db only stores handles — names came through only when another source (Gmail headers, Google Voice, WhatsApp --contacts) had already populated participants.display_name.

Two changes that together let names appear:

• Stop poisoning display_name with the phone string when the iMessage importer creates a new participant. The previous behavior left display_name = "+15551234567", which blocked later imports from filling in a real name (the update guard only writes when display_name is NULL/empty). New iMessage rows now leave display_name empty and let the first name-bearing import win.

• Add --contacts <vcf> to import-imessage, mirroring WhatsApp's flag. Backfills names by phone and email from a vCard export (e.g. macOS Contacts.app → File → Export → Export vCard). Only updates participants that already exist with an empty display_name, so any prior name is preserved.

Plumbing

• Extract the vCard parser into a new internal/vcard package so iMessage and WhatsApp share it (whatsapp.ImportContacts now wraps it). The parser also reads EMAIL fields, not just TEL/FN.
• Add Store.UpdateParticipantDisplayNameByEmail — case-insensitive, first-writer-wins, never creates rows.

Usage

msgvault import-imessage --contacts ~/contacts.vcf

Output now includes:

Contacts applied:
  Source:           ~/contacts.vcf (1234 entries)
  Names backfilled: 412 by phone, 38 by email

[roborev-ci]

roborev: Combined Review (c4911d6)

Summary verdict: One medium issue remains; no high or critical findings were reported.

Medium

• internal/store/messages.go:1226 - The iMessage contacts backfill only updates empty display_name values, but existing imports may have stored phone numbers as display_name. For upgraded users, import-imessage --contacts will not replace those legacy placeholder names with vCard names, limiting the backfill for the main existing-data case. Treat legacy placeholders as empty during iMessage contact backfill, for example by allowing updates when display_name = phone_number for participants with an iMessage identifier, while still preserving real names from other sources.

---

Synthesized from 3 reviews (agents: codex, gemini | types: default, security)

[bjabes]

Pushed 122189b to address the legacy-placeholder feedback.

import-imessage --contacts now uses a new Store.UpdateImessageParticipantDisplayNameByPhone that overwrites when:

• display_name IS NULL / empty (existing behavior), or
• display_name = phone_number (legacy placeholder), gated on the participant having an imessage identifier so other-source participants are never touched.

Test (TestUpdateImessageParticipantDisplayNameByPhone) covers all three cases: legacy placeholder cleared, real Gmail name preserved, non-iMessage participant untouched. The email path is unchanged — iMessage email handles were never poisoned.

[roborev-ci]

roborev: Combined Review (122189b)

Findings: two medium issues need attention before merge.

Medium

• internal/vcard/vcard.go:35 - The parser unfolds continuation lines before handling quoted-printable soft breaks, so a valid wrapped value like FN;ENCODING=QUOTED-PRINTABLE:Jo=C3=A3o da =\r\n Silva becomes ... da =Silva and decodes with a literal = in the name. Handle quoted-printable soft breaks during unfolding, or join QP soft breaks before normal continuation folding.

• internal/vcard/vcard.go:91 - vCard property groups such as item1.TEL and item1.EMAIL are not recognized because matching only checks for lines starting with TEL or EMAIL. These grouped properties are common in vCard 3.0 exports, including Apple Contacts-style files, so valid contact phones/emails can be skipped. Strip an optional group prefix before matching the property name, then handle TEL, EMAIL, and FN from the normalized key.

---

Synthesized from 3 reviews (agents: codex, gemini | types: default, security)

[roborev-ci]

roborev: Combined Review (44d9f7d)

Summary verdict: One medium correctness issue needs fixing before merge.

Medium

• internal/store/messages.go:1291 - RetitleImessageDirectChats can skip email-only iMessage direct chats. The query matches email-titled chats, but p.display_name != p.phone_number is not NULL-safe; when phone_number is NULL, the comparison evaluates to UNKNOWN, so Apple ID/email participants whose display names were backfilled may remain titled as the email address.

  Fix: Make the placeholder check NULL-safe in both the title subquery and EXISTS predicate, for example:

  p.phone_number IS NULL OR p.display_name != p.phone_number

  Add a regression test for an email-only direct iMessage chat.

---

Synthesized from 3 reviews (agents: codex, gemini | types: default, security)

[roborev-ci]

roborev: Combined Review (9205e44)

Clean: no Medium, High, or Critical findings were reported.

All reviewed outputs agree there are no actionable issues to include.

---

Synthesized from 3 reviews (agents: codex, gemini | types: default, security)

[wesm]

Thanks for working on this, I hadn't yet looked into how to get people's names into the whatsapp/imessage screens. I need to see how this composes with the other open PRs so bear with me

[roborev-ci]

roborev: Combined Review (7081192)

Duplicate imports and incomplete sender-name filtering remain; no Critical or High findings were reported.

Medium

• internal/importer/pst_import.go:515
  Changing PST source_message_id from pst-<EntryID> to pst-<archiveID>-<EntryID> breaks idempotence for PSTs imported before this change. Re-importing the same archive after upgrade will not match existing rows and can duplicate messages under the same source.
  Fix: Add legacy-key handling during import, such as checking for pst-<EntryID> and migrating it to the namespaced key or treating either key as an existing message before ingesting.

• internal/query/duckdb.go:733
  DuckDB sender-name aggregate search still does not include phone_number in the sender-name key columns, even though the visible aggregate key now falls back to phone numbers. A phone-only sender can appear in ViewSenderNames but disappear when searching/filtering that aggregate by the displayed phone number.
  Fix: Include pAlias + ".phone_number" in the ViewSenderNames keyColumns, matching the recipient-name update and the new participantNameExpr fallback.

---

Synthesized from 3 reviews (agents: codex, gemini | types: default, security)