* docs(plans): add the B1 repository-foundation execution plan B1 is the isolated layout/contributor phase. This records the execution order, the proof for each step, and what is out of scope. Two findings worth surfacing before any B1 work starts: - HP-0 was never formally accepted. The roadmap's B1 entry gate requires it; no scorecard artifact exists, no commit or document records an acceptance, and the B0 baseline still lists "Step 10: HP-0 sign-off" under "Not yet done in B0". The plan lists the five gaps that closing it requires, including pinning required status checks on dev -- which are still unset, so a dev PR can currently merge red. - Several layout-audit claims do not survive verification against HEAD, matching the B0 pattern. RL-09's "no single command verifies both protocol consumers" is false (make protocol-verify does, and is enforced in CI, the pre-commit hook, and a contract test). RL-10's test-discovery side effect never fires (no _test.go in Server/scripts). RL-06's regeneration concern is refuted locally. RL-08 grows a toolchain constraint instead. RL-05, RL-07, RL-20 and RL-21 are each worse than written -- RL-20 includes a live bug where a missing `make` is reported as stale protocol constants. The riskiest item, RL-01 (flatten Client/tauri-client into Client), gets a full reference inventory and a mechanical proof for both commits: tree- object equality for the pure move, and scripted-substitution replay for the path rewrite. Release asset names and updater contracts are verified independent of the directory name, so the move cannot rename an artifact. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * docs(plans): correct the B1 status-check pin list from a live dev PR The list was derived from ci.yml. Observing PR #1410's actual checks found three that exist in no workflow file -- Analyze (go), Analyze (javascript-typescript), Analyze (actions) -- because CodeQL runs from GitHub default setup, configured in repository settings. Reading .github/ alone misses them. Also confirms the two negative predictions against a real dev-targeted PR: Server Docker Build (verify) reports as "skipping", and Tauri Full Build never appears in the check list at all. Neither may be pinned. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * docs(plans): accept HP-0 and pin the dev required status checks Closes B1's entry gate. All five B1-0 items are done. The scorecard is the artifact the hold point asks for: one place that answers its four questions, records what was accepted as a stated limitation rather than claimed green, and part-closes R-08. Required status checks are now pinned on dev -- ten of them. That was B0's one outstanding step. Two things came out of doing it: - The names cannot be inferred from ci.yml. Three of the ten (the Analyze jobs) exist in no workflow file, because CodeQL runs from GitHub default setup configured in repository settings. They were read off a live dev-targeted PR with `gh pr checks`. - Server Docker Build, Tauri Full Build and the CodeQL aggregate are deliberately excluded. The first two report "skipping" on a dev PR -- Tauri Full Build under its unexpanded matrix name, since the job is skipped before matrix expansion. Admin Panel E2E is excluded because continue-on-error makes it report success unconditionally. Two prior claims are corrected rather than left to propagate: - b0-dev-branch-protection.sh was written assuming repository-settings writes are blocked from the agent sandbox. They are not; the PUT succeeded. The script stays as the record of intent and the way to re-apply or undo. - An earlier revision of the B1 plan said Tauri Full Build does not appear in a dev PR's check list at all. It does, as skipping. Evidence closed out: - Rust is no longer a carried row. Re-measured: 115 passed, cargo clippy --all-targets -- -D warnings at exit 0, confirming the carried figure. - The 38 open ledger records are accepted as counted, non-stale and assigned: 11 medium / 27 low, zero high or critical, zero dead paths across all 348 re-verified at this commit, and none assigned to B1. - The private security review is reconciled: 7 findings, 7 of 7 mapped to existing public rows, 0 unmapped. Summary is content-free; the detail stays in the untracked private reports. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
OwnCord
A self-hosted chat app I build for me and my friends — text channels, voice and video, and a server you actually own.
Alpha, and a hobby project. This is something I build for fun and run for a small group of friends. It isn't a product, there's no support, and it isn't production-ready. Expect rough edges, rapid changes, and the occasional breaking change.
Don't use it for anything sensitive.
It's a Go server plus a Tauri desktop client: real-time messaging, voice/video via LiveKit, file sharing, and a web admin panel. Run the server on a spare box or a VPS, hand your friends an invite code, and that's the whole thing.
How it's built
Most of the implementation is generated with AI tooling, with quality held up by automated checks — CI, tests, linting — and by me and my friends actually using it. That keeps iteration fast, and it also means behaviour can change quickly between releases.
What works right now
| Area | Status |
|---|---|
| Core chat flow | Working in alpha |
| Voice/video | Working in alpha |
| Admin panel | Working in alpha |
| Security hardening | Ongoing review passes; findings and their statuses are tracked in the dated audits in docs/ (see the Docs Index below) |
Platform Support (Current Releases)
| Component | Windows x64 | Linux x64 | Linux ARM64 |
|---|---|---|---|
| Server binary | Yes | Yes | Not yet |
| Desktop client | Yes (NSIS installer) | Yes (AppImage, .deb) | Yes (AppImage, .deb) |
| Docker server | N/A | Build from source (compose) | Not yet |
Start Here
- New user quick path: docs/quick-start.md
- Linux Docker deployment: docs/deployment.md
- Remote access without router config: docs/tailscale.md
- Manual router/network setup: docs/port-forwarding.md
Quick Start
Option A: Prebuilt binaries
- Download assets from Releases (binaries, checksums, signatures, and a full source snapshot per release).
- Run the server binary:
- Windows:
chatserver.exe - Linux:
./chatserver
- Windows:
- Open
https://localhost:8443/adminand complete the setup wizard — it creates your Owner account and configures the server for you (settings are saved toconfig.yamlautomatically). - Generate invite codes in the admin panel and share them with friends.
Option B: Docker (Linux server)
cd Server
cp .env.example .env
cp livekit.yaml.example livekit.yaml
# Edit both files before starting
docker compose up -d
See the full setup guide in docs/deployment.md.
The client uses TOFU (Trust On First Use) for self-signed certificates: it prompts once, then pins the certificate for future connections.
What OwnCord Already Has
- Real-time channels and direct messages over WebSocket
- Voice/video channels via LiveKit — the LiveKit server binary is downloaded and managed for you
- Invite-only registration and role-based permissions
- Web admin panel with logs, backups, and update tooling
- File uploads and inline media rendering
- TOTP 2FA support and API rate limiting
- Desktop client auto-update with signature verification
- WASM plugin system (slash commands; sandboxed, default-disabled — enable via
plugins.enabledand build with-tags wazero) - GIF picker — off by default; each server supplies its own
Klipy key via
gif.api_key(setup)
See deeper feature and architecture docs in docs/architecture/ and docs/protocol.md.
Architecture
Two main components:
- Go server (REST API, WebSocket hub, SQLite, admin panel)
- Tauri v2 desktop client (Rust backend + TypeScript frontend)
+---------------------+ +---------------------+
| OwnCord Client | | OwnCord Server |
| (Tauri v2) | | (Go) |
| | | |
| +---------------+ | WSS | +---------------+ |
| | Chat UI |--+------->| | WebSocket Hub| |
| +---------------+ | | +---------------+ |
| +---------------+ | HTTPS | +---------------+ |
| | REST Client |--+------->| | REST API | |
| +---------------+ | | +---------------+ |
| +---------------+ | LiveKit | +---------------+ |
| | Voice/Video |--+------->| | LiveKit SFU | |
| +---------------+ | | +---------------+ |
+---------------------+ | +---------------+ |
| | SQLite DB | |
| +---------------+ |
+---------------------+
Build and Test
Prerequisites
- Go 1.26+
- Node.js 20+
- Rust stable (client builds)
Build from source
# Server (Windows)
cd Server
go build -o chatserver.exe -ldflags "-s -w -X main.version=1.2.0-alpha.3" .
# Server (Linux)
cd Server
CGO_ENABLED=0 go build -o chatserver -ldflags "-s -w -X main.version=1.2.0-alpha.3" .
# Client
cd Client/tauri-client
npm install
npm run tauri build
Core verification commands
# Server
cd Server
go test ./...
# Client
cd Client/tauri-client
npm run typecheck
npm run lint
npm test
For the full command set, use docs/contributing.md.
Configuration
On first run, the server generates config.yaml and a local data/ directory:
data/
├── chatserver.db
├── certs/
├── uploads/
└── backups/
Key options include TLS mode, upload limits, LiveKit settings, and admin CIDR restrictions. See docs/server-configuration.md.
Security and Vulnerability Reporting
- For vulnerabilities, use GitHub Security Advisories (private disclosure flow).
- Do not open public issues for security bugs.
- Read full policy and hardening notes in docs/security.md.
Update Signing Notes (Maintainers)
Client and server update signing keys are intentionally separate.
Required Actions secrets for release signing:
TAURI_SIGNING_PRIVATE_KEYTAURI_SIGNING_PRIVATE_KEY_PASSWORDSERVER_UPDATE_SIGNING_PRIVATE_KEYSERVER_UPDATE_SIGNING_PRIVATE_KEY_PASSWORD
When rotating the server updater key, update Server/updater/server_update_public_key.txt and use staged rollover for live fleets.
Docs Index
- docs/quick-start.md
- docs/deployment.md
- docs/livekit-setup.md
- docs/port-forwarding.md
- docs/tailscale.md
- docs/architecture/ — system blueprints (diagrams + flows)
- docs/audit-2026-08-04-docs-and-coverage.md — latest full audit (docs accuracy, UX flow coverage, test runs)
- docs/audit-2026-08-04.md — latest security review
- docs/audit-2026-07-19.md — architecture & spec-conformance audit
- docs/api.md
- docs/protocol.md
- docs/schema.md
- docs/architecture/client.md — client architecture (replaces client-architecture.md)
- docs/architecture/ux/ — client UX specification (target-state flows, per-view states, event→reaction maps)
- docs/server-configuration.md
- docs/credential-storage.md
- docs/mcp-introspect.md — dev-only MCP server for introspecting a running instance
- docs/audit-test-coverage-2026-07-25.md — test-coverage audit
- docs/audit-2026-04-07.md — first comprehensive audit
- docs/plans/ — design plans and decision records (each carries a verified status header)
- docs/contributing.md
- docs/security.md
Contributing
- Create a branch from
dev(the active development branch). - Keep changes focused and tested.
- Open a PR targeting
dev—devis merged tomainfor releases.
See docs/contributing.md for the full process.
License
AGPL-3.0


