Bernd RodlerandClaude Sonnet 5
b966d285a9
An on-device, SQLCipher-encrypted full-text index the app can retrieve from to
feed an LLM ("prompt against"), for the Electron desktop shell only.
Shape: no persistent background worker and no resident credential. Indexing is
a normal request-scoped API route, triggered by the renderer's EXISTING live
JMAP push connection - so it reacts to each delivery/change rather than polling.
- lib/mail-index/binding.ts guarded require of the optional native binding
- lib/mail-index/paths.ts the VNCMAIL_DESKTOP_STORE_DIR gate + hashed paths
- lib/mail-index/store.ts schema, upsert, FTS5 search, encryption assertion
- lib/mail-index/extract.ts PURE JMAP-object -> document extractors
- lib/mail-index/jmap.ts minimal stateless server-side JMAP client
- lib/mail-index/key.ts per-job key fetch over the inherited fd
- lib/mail-index/reindex.ts the job + slot->account resolution
- electron/key-service.ts safeStorage wrap/unwrap, served over fd 3
- app/api/offline/reindex POST, event-driven + catch-up
- app/api/offline/search GET, the retrieval surface (hits + contextBlock)
- lib/mail-index-client.ts renderer client; StateChange -> index call
- components/settings/local-index-settings.tsx status + manual catch-up
Decisions worth knowing:
* `@signalapp/sqlcipher` is an OPTIONAL dependency with a guarded runtime
require. It publishes six N-API prebuilds and NO build sources, and both
Dockerfiles are node:24-alpine (musl, no matching prebuild) - as a hard
dependency it would break the production image and the integration fixture's
webmail container, neither of which wants this feature.
* Credentials come from the existing per-slot encrypted `jmap_stalwart_ctx`
cookie via lib/stalwart/credentials.ts - the same helper /api/settings and
/api/push/preview already use. It carries a ready-made header for basic AND
bearer accounts, so the indexer never touches the OAuth refresh-token cookie;
a server-side refresh would rotate a token into a response nobody reads and
silently log the user out.
* The encryption key crosses main -> server over an INHERITED FILE DESCRIPTOR,
never an environment variable: env is readable by any process running as the
same OS user, which would defeat using the OS keychain at all. Fetched per
job and zeroed after, so there is no long-lived key copy.
* safeStorage's Linux `basic_text` backend (no keyring) is treated as refusal,
not degradation - it "encrypts" with a hardcoded public password, which would
look like an encrypted mailbox while providing nothing.
getSelectedStorageBackend() is Linux-only and platform-guarded.
* Every store open asserts `PRAGMA cipher_version` returns a non-empty STRING,
not merely a row: a non-cipher binding returns ZERO ROWS, so a row-count check
would pass vacuously while writing the mailbox to disk in cleartext.
* Files are indexed by name/path/date/size only - NOT by extracted content.
Text extraction from arbitrary PDFs/office documents is a separate problem.
* Account-scoped composite keys `(jmap_account_id, content_type, id)` are kept
even though there is one file per account: one login exposes delegated/shared
JMAP accounts too, and JMAP ids are unique only within an account.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
52 lines
2.2 KiB
TypeScript
52 lines
2.2 KiB
TypeScript
// The hosted-deployment gate, and where an account's index file lives.
|
|
//
|
|
// The standalone Next.js server in `electron/main.ts` is the SAME artifact the
|
|
// production `Dockerfile` ships to multi-tenant deployments. An index that
|
|
// activated unconditionally would have a shared server start writing every
|
|
// user's mail into a server-side SQLite file. So activation is keyed on an env
|
|
// var that ONLY `electron/main.ts` sets, and that same var supplies the path -
|
|
// one variable doing both jobs, so they cannot drift apart.
|
|
|
|
import { createHash } from 'node:crypto';
|
|
import path from 'node:path';
|
|
|
|
/** Set by electron/main.ts on spawn. Absent => the feature does not exist. */
|
|
export const STORE_DIR_ENV = 'VNCMAIL_DESKTOP_STORE_DIR';
|
|
|
|
/**
|
|
* The index root, or `null` when this process is not the desktop shell's
|
|
* server. Every route must 404 on `null` - not 403, since nothing should learn
|
|
* the routes exist in a deployment that doesn't have the feature.
|
|
*/
|
|
export function getStoreDir(): string | null {
|
|
const dir = process.env[STORE_DIR_ENV]?.trim();
|
|
if (!dir) return null;
|
|
// Must be absolute: a relative path would resolve against the server's cwd,
|
|
// which differs between `electron:dev` and a packaged build.
|
|
if (!path.isAbsolute(dir)) return null;
|
|
return dir;
|
|
}
|
|
|
|
/**
|
|
* Filenames are a hash, not `username@host`, so a directory listing is not a
|
|
* plaintext inventory of the user's accounts. The account id itself lives only
|
|
* inside the encrypted file (and in the renderer's own `account-registry`,
|
|
* which already stores it in plain localStorage).
|
|
*/
|
|
export function accountFileToken(accountId: string): string {
|
|
return createHash('sha256').update(accountId, 'utf8').digest('hex').slice(0, 32);
|
|
}
|
|
|
|
export function indexDbPath(storeDir: string, accountId: string): string {
|
|
return path.join(storeDir, 'index', `${accountFileToken(accountId)}.db`);
|
|
}
|
|
|
|
export function keyFilePath(storeDir: string, accountId: string): string {
|
|
return path.join(storeDir, 'keys', `${accountFileToken(accountId)}.bin`);
|
|
}
|
|
|
|
/** WAL siblings must be removed with the database, or a purge leaks readable pages. */
|
|
export function dbSiblings(dbPath: string): string[] {
|
|
return [dbPath, `${dbPath}-wal`, `${dbPath}-shm`];
|
|
}
|