-
Notifications
You must be signed in to change notification settings - Fork 7
Why this exists
Issue #549 asks for a precise privacy and data-locality explanation, while #445 is the future native protected-storage authority. This Q&A is intended to clarify current behavior without promising future R-15 functionality.
Current product boundary
Browser/PWA project storage: project data is stored locally in the browser's IndexedDB/related local storage path. Optional IndexedDB at-rest protection is a separate capability and does not mean every browser-stored project is encrypted by default.
Transitional desktop filesystem storage: the current Tauri/transitional desktop project-file path remains plaintext until R-15. There is no current tauri-plugin-stronghold or OS-keychain-backed project-storage authority. Local desktop storage is therefore not represented as already encrypted project storage.
Future R-15 native protected storage: #445 defines the renderer-neutral encrypted desktop-storage program and its durability/recovery requirements. It is planned work, not a claim that the current desktop project-file path is already protected.
API credential protection: API credentials are handled separately from project documents through the app's credential-protection path and are encrypted at rest according to the current platform-specific mechanism. Credential protection must not be generalized into a claim that project files are encrypted today.
Collaboration transport: real-time collaboration transport uses the repository's E2E-encrypted collaboration path, including authenticated encrypted data channels. Transport protection does not change the storage authority or guarantee that every participant's local copy is encrypted at rest.
Browser-local AI: explicitly selected browser-local WebGPU/WASM or equivalent local inference keeps the inference payload on the user's device, subject to the model/runtime and browser capabilities. There is no hidden local-to-cloud fallback.
Local-network Ollama: an explicitly selected Ollama or other local-network endpoint receives data over the user's configured local network path. That is local-network processing, not a WorldScript-hosted cloud proxy, but network and endpoint trust remain the user's responsibility.
Direct cloud providers: when the user explicitly selects a cloud provider, the relevant prompt or document context is sent to that provider under the provider's service and retention terms. The app does not imply that a direct provider call is local processing.
WorldScript-hosted proxy paths: WorldScript is an offline-first client and does not currently operate a general project-data proxy. Any future feature that introduces a WorldScript-hosted proxy must disclose that path separately; it must not be inferred from the local or direct-provider descriptions above.
Role perspectives
Role-perspective note: The viewpoints below are maintainer-curated, AI-assisted design lenses. They are not separate community members, votes, or evidence of consensus.
- 🔐 Security explainer: distinguish storage, transport, credentials, inference location, and future protected-storage claims.
- ✍️ Privacy-focused author: make data locality and provider choice understandable before writing or AI actions occur.
- 🌐 Browser/native distinction: explain what the PWA, transitional desktop, and future R-15 authority each do today.
Questions
- Which privacy boundary is still unclear?
- Which provider, local-network, or browser-local choice needs a more visible explanation?
- What recovery and encryption evidence would make the future R-15 boundary trustworthy?
Relationship to implementation
#549 remains the current privacy/data-locality discussion and issue authority for its scope. #445 remains the future native-storage authority; this Q&A does not imply that R-15 is implemented, does not change either Issue's priority or acceptance criteria, and does not provide an accepted answer automatically.