Help · 3 / 5
Data and system
Projects and roles, where your data lives, how the system works
Workspaces, projects and roles
- Workspace. Each knowledge base is a workspace with its own members, credentials, templates and settings. One account can belong to several workspaces and switch between them under Settings → Knowledge bases.
- General and projects. Every workspace has a reserved General scope and can have project scopes, created by hand or synced from Multica. Archived projects keep their notes and history.
- People. Admins have full access to General, every project and the workspace rules, and manage members, invitations, credentials, templates, AI settings and integrations. Editors get read and write access to everything by default; an Admin can instead set no access, read, or read and edit for General and each project, and workspace-rules access separately.
- Agents. A Reader credential is read-only (by default General, all projects and the workspace rules). A Librarian is a separate credential with explicit write grants for General and/or selected projects. OAuth connections are always Readers. Credentials never inherit a person's access, and selectors such as
scope=allonly choose among content the caller can already read.
Your data and security
- What leaves your server. When you press auto-ingest, send a chat message or run a deep lint, the note text the agent reads is sent to the model provider configured for that run (OpenRouter may forward it to the selected model provider). Pasted URLs are fetched by your server; DOIs are looked up at Crossref. No product analytics are sent to a Central LLM Wiki service.
- What the agent can and cannot do. MCP tools include project discovery and resolution, reading instructions, searching and reading notes, reading history, and listing folders. Create and update tools are offered only to Librarian credentials with a write grant; every call checks access to its selected scope, and General has separate permissions. The agent cannot update or delete raw/, cannot delete any page, cannot browse the web, and never sees your API key. Every write is versioned and attributed to the agent and model, and can be rolled back. Automatic ingest jobs cannot write to schema/. Source content does enter the agent's prompt and is treated as data, not instructions; version history is your recovery path.
- API key. Encrypted with a key separate from the login secret, only the last four characters are shown, decrypted only when a job starts or when testing the connection, deletable at any time.
- Export. Settings offers the whole wiki as a Markdown zip (with image attachments, opens in Obsidian), plus .bib and CSL-JSON. The zip excludes version history, deleted pages, chat transcripts and agent job logs.
- Sources cannot be deleted. raw/ is the immutable source layer: neither the web nor the agent can delete it. Press Archive on a source you no longer want to see; it moves under raw/archive/, drops out of the pending list, keeps versions and links, and can be unarchived any time.
- Retention. The latest version of every page is kept until it or its workspace is deleted; older snapshots are kept for 90 days by default (the operator can change this). Deleting your account deletes your workspace and everything in it; remove other members first.
- Source code. The full source code is published under the Apache-2.0 license on GitHub.
How the system works
One Bun service serves the MCP server, the web API, the OAuth authorization server and the web app; all data lives in the PostgreSQL instance you configure; there is no vector database and no RAG. Request rate limits help protect each deployment, and only one server-side agent job runs at a time per workspace.
How knowledge flows between the three layers (the operations run in a remote agent via MCP, or in the optional web agent with your key):