brutsalvadi
39 lines
2.0 KiB
Markdown
39 lines
2.0 KiB
Markdown
# BincioWiki — Developer Documentation
|
|
|
|
BincioWiki is a private, invite-only wiki for the Bincio group of friends. It is built around a small set of deliberate constraints:
|
|
|
|
- **Git-native content.** Every page edit is a git commit with author attribution. The wiki's history is the edit history.
|
|
- **No CMS complexity.** Content is plain Markdown files on disk. No database for content, no object storage, no CDN.
|
|
- **Shared identity.** Authentication is shared with `bincio_activity` via a single SQLite database. One account, two apps, one session cookie.
|
|
- **Client-side auth enforcement.** The HTML is publicly served by nginx; JavaScript redirects unauthenticated users to `/login/`. This is an intentional tradeoff — the content is community memories, not financial data, and the goal is keeping crawlers and casual visitors out, not resisting determined attackers.
|
|
- **Self-hosted on a cheap VPS.** Everything runs on a single Hetzner Debian 12 VPS.
|
|
|
|
## Repository structure
|
|
|
|
```
|
|
bincio_wiki/
|
|
pages/ wiki content (*.md — edited by community)
|
|
blog/ blog/stories content (*.md)
|
|
config/ bincio-specific config (outside the submodule)
|
|
sections.json wiki section + subsection definitions
|
|
i.bonsai.md wikibonsai semantic tree
|
|
assets/ user-uploaded images (gitignored, rsync'd separately)
|
|
site/ Astro 6 app (git submodule → brutsalvadi/astro-bloomz)
|
|
edit/ FastAPI edit sidecar (Python, port 4042 prod / 8001 dev)
|
|
docs/ this documentation
|
|
scripts/ dev.sh, sync-vps.sh
|
|
deploy/ VPS config files (nginx, systemd, post-receive hook)
|
|
pyproject.toml Python dependencies (managed by uv)
|
|
```
|
|
|
|
## Two-repo model
|
|
|
|
The project uses two git repositories:
|
|
|
|
| Repo | Purpose |
|
|
|------|---------|
|
|
| `bincio_wiki` (container) | Content (`pages/`, `blog/`), sidecar, config, scripts |
|
|
| `brutsalvadi/astro-bloomz` (submodule at `site/`) | Astro rendering engine |
|
|
|
|
This separation keeps content history out of the engine submodule and allows the engine to be reused or forked independently.
|