Signal over noise. Structure over spectacle.
VOIDcore is a self-hosted typed-document community platform with terminal aesthetics and BBS-flavoured social primitives. It is for communities that want their knowledge to be durable, queryable, and theirs — instead of losing it inside chat silos and SaaS dashboards.
The substrate is opinionated and small: typed Markdown documents validated against operator-definable schemas, with first-class conversation primitives (chat, threads, mail, mentions) that stay in their own lane.
- public split is live as a standalone repo
- Docker Compose stack boots with
postgres,app, andcityline-door - the user-facing surface has started the move from "releases" toward the more generic "files" model
- the project is usable now, but still in active extraction and polish
- Typed Markdown documents with schema-driven frontmatter and revisions
- Message boards, chat, mail (VoidMail), and mentions as separate first-class primitives
- Doors — sidecar processes that hang off the BBS; the bundled Cityline MUD is the worked example
- Terminal-native UI in the browser — no separate client to install, no Electron, no mobile app
The current extension contract is intentionally small:
- branding and instance-shaping via env vars and built-in feature toggles
- overlay-owned SQL migrations mounted into Flyway
- startup-loaded overlay themes under
/instance/themes - startup-loaded ANSI skins under
/instance/skins - sidecar applications via the door protocol
- an internal named custom-screen routing seam that future in-process extensions can build on
For local development, the repo ships a worked example instance root at
app/dev-instance. That
includes a WS/360 theme, a manifest-backed ws360/demo custom screen, and
sample ANSI skins. Production deployments should still point
VOIDCORE_INSTANCE_ROOT at their own external overlay path.
The repo does not yet promise a finished operator-facing in-process plugin
boundary for private Screen classes, manifests, or scripts. See
docs/extending-voidcore.md for the current
supported contract and its limits.
git clone <repo-url> voidcore
cd voidcore
docker compose up --buildThen open http://localhost:8080.
That's it. The default stack builds the app from source, starts Postgres,
applies all migrations, boots VOIDcore on 127.0.0.1:8080, and starts the
bundled Cityline MUD door on 127.0.0.1:8081.
The first user to register is just a regular member. To bootstrap a sysop
account on first boot, set SYSOP_HANDLE and SYSOP_INITIAL_PASSWORD in
.env before docker compose up — see .env.example.
All env vars are optional and have working repo defaults. Copy
.env.example to .env only if you want to override ports, DB
credentials, the sysop bootstrap, or Flyway overlay locations.
cp .env.example .env
make secrets >> .env # generate strong DB and sysop passwordsUseful Make targets: make up, make down, make logs, make psql,
make secrets, make env-check. Run make help for the full list.
docker compose up brings up three services on the local loopback:
postgres— Postgres 17 with VOIDcore's schema and Flyway migrationsapp— VOIDcore on127.0.0.1:8080(HTTP + WebSocket)cityline-door— example MUD door, reachable through VOIDcore's door framework on127.0.0.1:8081
No backup sidecars, deployment automation, or instance-specific ops tooling are carried in this public-engine repo — those belong in your own deployment overlay.
- SPEC.md — wire protocol and screen contracts
- SPEC-documents.md — typed-document model
- SPEC-screens.md — screen architecture
- SPEC-screen-navigation.md — navigation model
- SPEC-doors.md — door protocol
- SPEC-layout.md — layout primitives
- docs/extending-voidcore.md — current overlay contract and extension hooks
- DECISIONS.md — architectural rationale (ADRs)
- ROADMAP.md — direction
End-user and sysop guides are planned but not yet written.
VOIDcore is licensed under GPL-3.0-or-later. See LICENSE.