Dropdat architecture

Capture a conversation, save it as portable memory, and reuse it across AI tools.

1. System overview

Extension, dashboard, and MCP clients connected to the shared Go API and data services.
Open full-size SVG

The browser extension captures and reuses conversations, the web dashboard manages the library, and the MCP bridge exposes saved context to coding clients. All three use a Go HTTP API backed by PostgreSQL. Clerk handles identity, R2 stores attachments, and OpenAI supplies embeddings.

A capsule is conversation JSON with a client-generated UUIDv7. The extension can save it offline in IndexedDB and sync the same ID later.

2. Drop a saved conversation

Capsule selection, context formatting, and insertion into a destination AI chat composer.
Open full-size SVG

The user selects a capsule. The extension formats its messages as plain-text context and inserts that text into the destination chat composer through a provider-specific injector.

This transfers conversation text, not hidden model state. The destination AI receives it when the user submits the message; Dropdat does not automatically run the model.

3. Capture and save

Capture a visible conversation, normalize a capsule, save locally, and attempt cloud sync.
Open full-size SVG

A provider adapter reads the visible conversation and normalizes messages, source metadata, and a stable capsule ID. IndexedDB stores the capsule before an authenticated API write is attempted.

If connectivity or plan limits block sync, the capsule remains pending locally. A later sync retries without requiring another capture.

4. Sync, images, and embeddings

Two-way capsule synchronization, image storage in R2, and background embedding generation.
Open full-size SVG

Two-way sync pushes pending capsules and pulls remote updates. Captured images are queued separately and uploaded after their capsule syncs. The API checks access, PostgreSQL holds attachment metadata, and R2 holds binary files.

Capsule writes schedule embedding generation in the background. Saving does not wait for it, and keyword retrieval remains available if embedding generation fails or is disabled.

5. Retrieval and MCP

Hybrid retrieval, capsule indexing, context assembly, and the MCP bridge.
Open full-size SVG

Hybrid search combines pgvector cosine similarity with PostgreSQL full-text ranking using Reciprocal Rank Fusion. Both indexes live alongside capsule data. When query embedding is unavailable, search uses the text leg only.

Related-capsule and dynamic-context endpoints assemble neighboring memory. The local stdio MCP server uses a scoped API key to expose tools such as dropdat_recall, dropdat_read, and dropdat_capsule to coding clients.

6. Deployment and services

Caddy, the static web app, Go API, PostgreSQL, Docker Compose, and external services.
Open full-size SVG

Caddy serves the static Next.js export over HTTPS and proxies /api/* to Go on port 8080. Docker Compose runs the infrastructure. External services provide authentication, attachments, embeddings, and billing.

GitHub Actions builds the frontend, generates sqlc code, transfers files over SSH and rsync, applies database migrations, and rebuilds containers. This architecture document is independent static HTML and CSS; it uses no Next.js layout, React runtime, or authentication.

7. Authentication and authorization

Clerk JWT verification, hashed API keys, route permissions, and API key management.
Open full-size SVG

Interactive clients use Clerk session JWTs. Go verifies their signatures through Clerk's public JWKS and checks expiry, issuer, and subject. Programmatic clients use dk_ API keys; only a SHA-256 hash of each key is stored.

Requests carry the owning user ID. Scope, plan, and resource-access checks control permitted operations. Authentication alone does not grant access to another user's private capsules.