Skip to main content

​
There is no provider abstraction

Unlike frameworks that let you swap in OpenAI, Vertex AI, or Ollama for embeddings, sovseal deliberately does not — each surface runs one fixed, hardcoded model, entirely on-device via Transformers.js. @sovseal/mcp-server runs Xenova/all-MiniLM-L6-v2 (ONNX, quantized, ~22 MB, 384-dim, SHA-256-pinned); @sovseal/extension runs intfloat/multilingual-e5-small (also 384-dim).
Currently diverged, not unified. A same-day model-integrity-pinning fix reverted the MCP server off a brief mid-development unification onto the extension’s model — the two surfaces do not currently share one vector space (see “Why the embedder is fixed” below for why that matters). This is being reconciled; track logs/escalation/EMBEDDER-minilm-e5-prefix-mismatch.md in the source repo for status.
There is no embedder.provider config key, no YAML configuration format, no server/ directory, and no Docker image to rebuild with a different embedder baked in. If you’ve seen documentation describing Ollama, Vertex AI, or OpenAI embedder providers for this project, that describes a different project’s plugin architecture.

​
Why the embedder is fixed, not pluggable

Two reasons, both structural rather than incidental:
  1. One shared vector space is the goal, even though it’s not the current state. The MCP server and the extension both write to the same conceptual memory graph and need to recall each other’s writes correctly. If either surface independently chooses a different embedder — which is exactly the current, temporary state, see the warning above — a memory captured in the browser becomes unreliably rankable from the MCP server: mismatched embeddings don’t error, they just rank badly, silently. The model being fixed per surface (not user-configurable) is what keeps this a tracked, fixable inconsistency rather than an open-ended combinatorial support problem across arbitrary user-chosen models.
  2. Zero-knowledge requires local inference. A managed embedding provider (OpenAI, Vertex AI) means your raw memory text leaves the device to be embedded — which breaks the entire premise. The only embedder options consistent with the architecture are ones that run on-device, and maintaining a matrix of on-device runtimes (ONNX vs. GGUF vs. Core ML, each with different quantization behavior) multiplies the same fork risk described above.

​
If you need a different model

This is a real limitation for some workloads — a 384-dim general-purpose multilingual model won’t be the best fit for every domain. There are two supported paths:
  • Self-host and modify the source. packages/sovseal-mcp-server/src/local/embeddings.ts (MCP server) and apps/extension/src/engine/embeddings.ts (extension) are where each surface’s EMBEDDING_MODEL is defined. Since both are open source, you can fork and swap the model — but you take on responsibility for keeping every consuming surface in sync, which is exactly the risk the default configuration exists to avoid.
  • Ask for it. If you have a concrete workload the default model handles poorly, enterprise@sovseal.com is the right channel — a per-deployment override is a reasonable request; a general plugin system is not currently planned, for the reasons above.

​
The two models, side by side

The MCP server’s embedder does not use e5-style prefixes — that convention is specific to the extension’s e5 model. Both run entirely on-device regardless.
See Zero-Knowledge for why local inference is load-bearing to the security model, not incidental to it.