status: current

See also: [[Design/Platform_Overview]], [[Design/Data_Model]], [[Design/Auth]], [[Design/VPS_Architecture]].

When a user creates a new wiki, the repo is initialized with a starter page set that teaches Claude how to use the wiki effectively. The user connects MCP, starts a conversation, and Claude already knows the conventions.

Premium users can create a wiki from any public (or authenticated) Git repo URL. The server clones the template repo, strips its git history, and commits the contents as the wiki's initial state. This enables:

Otterwiki stores attachments as regular files in the git repo and serves them directly from the working tree.

Store attachments in the git repo as-is. Tier limits (50MB free, 1GB premium) keep repo sizes manageable.

If large attachments become a problem (disk usage, Git remote clone times), decouple attachment storage from the git repo:

1. On upload: store the attachment externally at a known path, commit only a lightweight reference file to git (similar to Git LFS pointer format)

- **Upstream patch** to Otterwiki adding a pluggable storage backend for attachments (local filesystem vs. external)

HTTP route (`/{user}/{wiki}.git/*`) served by the app implementing Git smart HTTP protocol (`git-upload-pack` for clone/fetch, `git-receive-pack` for push). Accesses the same on-disk repo as the wiki handlers.

Bidirectional sync with an external remote (GitHub, GitLab, etc.). Triggered on schedule or webhook:

1. Open wiki repo

| Git repos (wiki content) | Local disk | **Critical** — user data, irreplaceable |

**Git repos**: rsync to off-site storage, daily. See [[Design/VPS_Architecture]] for specifics.

**Platform DB**: Daily dump + rsync. Point-in-time recovery if using PostgreSQL.

**FAISS indexes**: No backup needed. Rebuildable from repo content (MiniLM runs locally, no API cost).

Git repos are the source of truth. Everything else (platform DB records, FAISS indexes) is either backed up independently or rebuildable from the repos.

User accounts and wiki data are retained indefinitely regardless of activity. Storage cost for an idle wiki is effectively zero. There is no reason to delete inactive accounts — it costs nothing to keep them and deleting user data is irreversible.

3. Deletes the user record from the platform DB

**Post-launch (when traffic justifies it)**: IP-based rate limiting via reverse proxy (nginx/Caddy). Geographic blocking, bot control, OWASP Top 10 rule sets via WAF or application-level middleware.

**Per-user rate limiting (premium launch)**: When premium tier ships, add per-user throttling on API and MCP endpoints. Define specific limits when the need materializes.