KMP Multi-Target: Native CLI (direct SQLite) + Chrome Extension (in-memory)

[guiyanakuang]

Motivation

The current CLI architecture (#3828, PR #3829 closed) uses an HTTP bridge to communicate with the running JVM app. This has fundamental problems:

• CLI cannot work independently — requires GUI app to be running
• Startup delay — launching JVM takes seconds for a simple query
• Resource overhead — full GUI + JVM for a crosspaste history command
• PATH setup depends on GUI launch — Linux /usr/local/bin needs root, macOS/Windows need app to run first

New Architecture

Leverage Kotlin Multiplatform's multi-target compilation to share commonMain code across Desktop, Native CLI, and Chrome Extension:

shared/              ← Core: models, DAO interfaces, SQLite impl
    commonMain       ← Interfaces + models (all targets)
    desktopMain      ← JVM SQLite driver
    nativeAppMain    ← Native SQLite driver

app/                 ← Desktop GUI (JVM + Compose, unchanged)
cli/                 ← Native CLI binary (direct SQLite access)
chrome/              ← Chrome Extension (future, JS target, in-memory)

DAO Interface Abstraction

All DAOs are interface-based, enabling different storage backends:

Target	Implementation	Storage
Desktop (JVM)	SqlPasteDao	Persistent SQLite
CLI (Native)	SqlPasteDao	Persistent SQLite (read-heavy)
Chrome Extension (JS)	MemoryPasteDao	Volatile (recent N items)

Chrome extension supports the same task/data model but without persistence — acts as a lightweight entry point that funnels users to the desktop app for full functionality.

Implementation Plan (20 Steps)

Phase 1: SQLDelight Migration to shared (Steps 1-4)

• Step 1 — Add native-sqlite-driver to gradle/libs.versions.toml (PR 🔨 Move SQLDelight to shared module, extract DAO interfaces, remove CLI bridge #3950)
• Step 2 — Configure SQLDelight plugin in shared/build.gradle.kts (PR 🔨 Move SQLDelight to shared module, extract DAO interfaces, remove CLI bridge #3950)
• Step 3 — Move 5 .sq files + migrations from app/ to shared/; remove SQLDelight from app/build.gradle.kts (PR 🔨 Move SQLDelight to shared module, extract DAO interfaces, remove CLI bridge #3950)
• Step 4 — Move DriverFactory interface + Int2LongAdapter to shared (PR 🔨 Move SQLDelight to shared module, extract DAO interfaces, remove CLI bridge #3950)

Phase 2: Move Model Classes (Steps 5-8)

• Step 5 — Move zero-dependency models: AppInfo, PasteTask, TaskStatus, TaskType, SyncState, ChangeType (PR 🔨 Move SQLDelight to shared module, extract DAO interfaces, remove CLI bridge #3950)
• Step 6 — Move pure interfaces: SecureIO, SearchContentService, PasteExportParam, TaskSubmitter (PR 🔨 Move SQLDelight to shared module, extract DAO interfaces, remove CLI bridge #3950)
• Step 7 — Move DTOs: SyncInfo, EndpointInfo (PR 🔨 Move SQLDelight to shared module, extract DAO interfaces, remove CLI bridge #3950)
• Step 8 — Move dependent models: SyncRuntimeInfo, PasteResourceInfo (PR 🔨 Move SQLDelight to shared module, extract DAO interfaces, remove CLI bridge #3950)

Phase 3: DAO Interface Extraction + Migration (Steps 9-12)

• Step 9 — Extract PasteTagDao interface + SqlPasteTagDao impl, move to shared (PR 🔨 Move SQLDelight to shared module, extract DAO interfaces, remove CLI bridge #3950)
• Step 10 — Extract SecureDao → SqlSecureDao + TaskDao → SqlTaskDao interfaces and impls (PR 🔨 Move SQLDelight to shared module, extract DAO interfaces, remove CLI bridge #3950)
• Step 11 — Refactor SyncRuntimeInfoDao: remove net.filter dependency, extract interface + SqlSyncRuntimeInfoDao impl, introduce ConnectInfo (PR 🔨 Move SQLDelight to shared module, extract DAO interfaces, remove CLI bridge #3950)
• Step 12 — Extract PasteDao interface + SqlPasteDao impl, move to shared (PR 🔨 Move SQLDelight to shared module, extract DAO interfaces, remove CLI bridge #3950)

Phase 4: Native Driver + CLI Foundation (Steps 13-15)

• Step 13 — Move dispatchers + LoggerExtension to shared, move Sql*Dao impls to shared/commonMain, create NativeDriverFactory in shared/nativeAppMain (PR 🔨 Move SQLDelight to shared module, extract DAO interfaces, remove CLI bridge #3950)
• Step 14 — Update cli/build.gradle.kts: add shared dependency, link system sqlite3 (PR 🔨 Move SQLDelight to shared module, extract DAO interfaces, remove CLI bridge #3950)
• Step 15 — CLI database DI: CliAdapters (CliReadOnlyAppConfig, CliConfigManager, CliPlatformUserDataPathProvider), NoOpServices, full DAO registrations including SecureIO (PR 🔨 Move SQLDelight to shared module, extract DAO interfaces, remove CLI bridge #3950)

Phase 5: Rewrite CLI Commands (Steps 16-18)

• Step 16 — Rewrite read commands: history, search, paste, status (HTTP → direct DAO)
• Step 17 — Rewrite write commands: delete, fav, tags
• Step 18 — Rewrite config + devices commands

Phase 6: Cleanup (Steps 19-20)

• Step 19 — Remove old HTTP bridge code: CliRouting, CliTokenManager, CliSymlinkService, CLI DTOs (PR 🔨 Move SQLDelight to shared module, extract DAO interfaces, remove CLI bridge #3950)
• Step 20 — CLI PATH discoverability: Linux (conveyor.conf symlink), macOS/Windows (evaluate approach)

Key Technical Decisions

• SQLDelight native driver (app.cash.sqldelight:native-driver) for Kotlin/Native SQLite access
• SQLite WAL mode for concurrent read access (CLI + Desktop app can read simultaneously)

[m13v]

the JVM startup cost for CLI is a real problem. we went with a native Swift binary that talks directly to SQLite for the same reason - even a 1-2 second delay makes a CLI tool feel broken. for the in-memory SQLite approach in the Chrome extension, one thing to watch is that you'll lose data on extension crash/update unless you persist periodically. we use WAL mode with periodic checkpoints which gives you the speed of in-memory with crash safety.

[m13v]

here's the SQLite layer we use with the persistence + migration pattern that works well for both CLI and GUI access: https://github.com/m13v/user-memories/blob/main/user_memories/db.py