Importer plugins: let a reader install a narrow, sandboxed importer instead of building per-app integrations #141

Not planned for now. Recorded so the shape is on hand once real demand accumulates.

Trigger

A reader wanted notes from Get笔记 (biji.com OpenAPI) in the reader. A built-in, one-off integration for a single note app does not fit the product, but a plugin the reader installs would keep the reader itself unaware of any particular app.

Shape

An importer plugin runs isolated (a Worker or sandboxed iframe, like Code Lab cells in ui-packages/code-lab/src/runtime/worker.ts) and never touches IndexedDB, files, conversations or memory directly. Its whole host API:

type ImporterHost = {
  fetch: typeof fetch                         // browser fetch, bound by the target's CORS
  settings: Record<string, string>            // values the reader enters for this plugin, such as an API key
  emit: (path: string, text: string) => void  // the reader writes the file; an existing file is never replaced
}

The assistant gets no new tool from this: importing is a reader action, so no prompt-injection path to send data out.

Before building

• Wait for two or three concrete importers (e.g. Get笔记, flomo, Readwise) and design the API from what they share; one example is not enough to fix a public interface.
• Open questions: install and update flow, where settings live, re-import (skip existing files is the simplest rule).

Notes from Get笔记

• openapi.biji.com answers CORS preflight with Access-Control-Allow-Origin: *, so the browser can call it directly.
• Note IDs are 64-bit; keep them as strings in JS.
• Note body format (Markdown / HTML / text) is unconfirmed.