Proposal: Spark Desktop as a local source for restricted work accounts

[eddowding]

Opening this as an exploratory proposal because GitHub Discussions are currently disabled for the repository. I am trying to test interest and agree the integration boundary, not commit to building it yet.

The access problem

My personal Gmail can continue using msgvault's native Gmail connector. The gap is employer-controlled mailboxes where custom OAuth applications are prohibited or require administrator approval.

Those same accounts may already be connected to Spark Desktop and explicitly permissioned for read access under Settings → AI Agents. Spark CLI then provides local access across Gmail, Outlook, Exchange, iCloud, Yahoo, and other IMAP/EWS accounts without configuring a separate provider API for each one. It also exposes Spark Meeting Notes.

That suggests Spark could be a useful local upstream source for mailboxes that msgvault cannot otherwise reach.

Possible boundary

• Spark Desktop remains the credential and permission owner.
• msgvault imports only accounts the user selects and has enabled for read access in Spark.
• No provider credentials or OAuth tokens are copied into msgvault.
• Each imported mailbox remains a distinct source with its own provenance, even when the underlying provider is Gmail.
• Spark Meeting Notes map into msgvault's existing meeting model.

What appears feasible today

The currently shipped Spark CLI (I inspected v1.3.1) can enumerate accounts and folders, page through messages, read complete threads, expose attachment metadata and stream attachment bytes, and retrieve meeting summaries, transcripts, and notes.

msgvault already has most of the corresponding downstream concepts: durable sources and identities, sync/checkpoint patterns, attachment storage, email importers, and a provider-neutral meeting import API.

The important limitation is fidelity. The public CLI currently emits human-readable output and does not expose structured JSON, raw MIME, a formal incremental-change cursor, or deletion events. So I would not call a CLI parser archive-grade until those gaps are resolved. Spark's private local data is useful evidence that stable provider identifiers exist and might help a disposable macOS prototype, but I would not propose private SQLite schemas as the upstream contract; that would be brittle and platform-specific.

Suggested staged path

1. Align on ownership: decide whether this belongs as a first-class spark source, a provider-neutral email/meeting import API plus a separate bridge, or outside msgvault.
2. Run a disposable contract spike: use only the public Spark CLI to measure completeness, throughput, stable identity, attachment handling, and meeting mapping.
3. Resolve fidelity gaps: preferably ask Spark for machine-readable output, stable change cursors, raw-message export, and deletion signals before promising archive-grade sync.
4. Optional normalized-content MVP: if byte-exact email is not required, implement searchable messages, attachments, meetings, checkpoints, and periodic reconciliation.
5. Production connector: add scheduling, deletion detection, CLI compatibility tests, documentation, and additional platforms only after the proof establishes a stable contract.

Questions

1. Is a locally installed desktop client an acceptable upstream dependency for a msgvault source?
2. Would you prefer native add-spark / sync-spark commands, or provider-neutral email/meeting import endpoints used by an external bridge?
3. Is normalized content acceptable for this source, or must every email source preserve original MIME?
4. Should Spark-imported Gmail coexist with native Gmail as separate provenance, or participate in cross-source deduplication?
5. Would an initial CLI-output parser be acceptable for a spike, or would you require a structured Spark export contract first?
6. If the idea fits, what minimum proof would you want before discussing implementation?