Skip to main content

​
Using Core with FogVault

Core 1.0 includes optional native Rust, Node, Python and browser integrations. They keep Core preparation separate from persistence and activate only after the exact candidate has been saved. The integration packages are version 1.0.0; FogVault is independently versioned 0.1.0. The reviewed Workspace contract is version 1. Core’s Rust 1.88 minimum and exact published 0.5.0-beta.3 interchange regression remain unchanged. Production-host acceptance remains separate.

​
Start here

The adapter owns the Core Workspace and its plans/streams. The application owns literal approval of the current review, authenticated tenant/routing context, credential input and transport. FogVault owns encryption and authenticated publication. Raw source text never needs to enter the chat site’s page to use this integration. Preparation is local review, not permission to copy or send.

​
Prepare and verify

Run the existing environment setup, then build Core’s bindings and inspect the repository-sourced prerequisites:
The explicit FogVault preparation command checks out exact public revision f4dc492549b70f0bc44f5c6bf82fe3022353030f into Core’s ignored target/fogvault-integration/dependencies/. It installs that candidate’s locked build tools, provisions Rust 1.94.1’s WASM target, builds/packages it there and packs Core’s current WASM package. It does not modify an existing FogVault checkout. Build logs, package hashes, pinned source identity and current dirty Core build/package input hashes are retained in target/fogvault-integration/. Checking does not install dependencies. It requires the prepared package bytes and Core build inputs still to match, runs named required Rust and actual installed browser cases, and rejects omitted/skipped/malformed results. Each run gets a fresh directory with logs, hashes and source identity. Do not reuse old passing evidence after changing source or package bytes. cargo dfv check --fogvault --native-only selects Rust migration/native tests; --browser-only selects the installed-browser and binding checks. The dfv entry point still uses Core’s full environment diagnosis. CI may invoke the same Python gate directly for a Rust-only host with its explicitly installed native prerequisites. A native subset is not browser qualification. The native integration has its own Rust 1.94.1 qualification toolchain and a tested minimum of Rust 1.89. Core itself stays on 1.88. Optional native Node and Python packages wrap that same Rust owner. They are separate from the existing Core SDKs, support password-only admission, and retain literal approval, complete-head save, lock/reopen and uncertain-outcome rules. Tenant/thread checks catch host routing errors; the application still owns authentication, path permissions and an independently protected native control namespace. Prepare and check the native language packages separately:
This selected scope diagnoses its own pinned native build tools and does not require unrelated original SDK outputs. Setup installs the declared Node build tools; checking never installs dependencies. It builds an actual npm tarball and Python wheel, installs each in a fresh consumer, runs named behavioral cases and type checks, then runs Node → Python → Node against the same registered SQLite vault and control namespace. Logs, package identities, source hashes and reports are retained in target/fogvault-language/check-*/. CI qualifies this installed path on Linux, macOS and Windows. It does not qualify production tenant routing, physical providers, power cuts or every Python/Node version. Core v1 and later publish workflows require all three qualification workflows for the exact release commit: all six native/browser scopes, all three native language OS scopes, the unified native Node archive and the browser model SDK scope. Pending, failed, incomplete or older-commit evidence blocks publication. This gate does not publish packages or replace release authorization. Both --fogvault and --fogvault-languages are required joint qualification scopes for changes that affect all maintained integrations. Neither publishes packages or changes the existing Core beta.3 minimum. Published versions and public-install evidence are recorded in the 1.0.0 release.

​
Browser extension handoff

  1. Pin the exact Core, FogVault and integration artifacts. Initialize Core; configure the FogVault Worker URL, finite resource/KDF policy and credentials in an extension-owned trusted page. A service worker’s memory is not storage.
  2. Give the adapter exclusive ownership of the supplied handles. Persist public routing identifiers so reopen selects the intended workspace/record.
  3. Prepare and display the local review. Editing, locking or changing ownership invalidates permission to hand off the old result. Commit only after explicit approval of that exact still-current plan.
  4. Hand off only the result of a confirmed save followed by Core activation. This does not establish remote delivery. Conversation intents must remain pending until the host saves a trusted observation of the actual send.
  5. On an uncertain save, retain the exact request ID, reconcile/reopen durable authenticated state and prepare/approve fresh work. Never infer rollback, reuse an old approval, fall back to unscoped restore or automatically resend.
  6. Lock through the adapter so Core is revoked immediately, before asynchronous vault cleanup. Clear application-owned source/preview copies separately.
The runnable browser example is integration code, not a completed shipping extension. Josh’s actual CSP/bundler/host send-observation acceptance remains Core issue #132 and gate G4. Browser tests use actual installed Core WASM, FogVault Worker and IndexedDB; synthetic host observations do not prove real chat-site identity or network delivery.

​
Release boundary

The owner-approved Core v1 release scope separates Core SDK qualification from extension-product acceptance. Core requires its contract freeze, installed package/parity checks and exact-candidate joint gates. External provider preservation and Josh’s shipping-site acceptance remain open product work; their thresholds have not been lowered or reported as passed. Core-owned integration packages 1.0.0 and independently versioned FogVault 0.1.0 are published. Registry archive identities and public-install behavior are verified separately from local candidate packaging. The release records retain both sets of evidence. CSV is deferred from Core v1. Resource observations support one pending integrated preparation. They do not establish arbitrary device memory budgets, physical power-loss guarantees or production key/provider qualification. The browser portion of cargo dfv check --fogvault --engine ENGINE also requires an installed import-only reader for the supported reference encrypted backup v1/v2 envelopes. cargo dfv build --fogvault explicitly prepares its pinned worker build dependencies. The check authenticates actual legacy files using both password and recovery paths, validates Core identity/head, and publishes only approved recovery into a fresh FogVault destination. It tests real cancellation, uncertain publication with cleanup failure, and fresh reconciliation/reopen. Named evidence is retained as legacy.json beside browser.json. This covers the non-shipping reference-host format; it does not establish the archive provenance or format of Josh’s shipping extension. The Core contract review and production extension security review are separate release decisions. See the reader scope and resource limits.