# Inbox

Quick capture zone. Process these notes during weekly review:

1. Delete junk.
2. Move actionable work to projects/tasks.
3. Promote durable knowledge to resources, runbooks, or decisions.
4. Archive stale items.

## Future ideas

### 2026-05-29 — Private self-hosted comms stack behind Tailscale Operator

Idea from Discord thread with Wrack: build a fully self-hosted Discord/Telegram replacement on the existing Kubernetes cluster, with services exposed privately only via the Tailscale Kubernetes Operator.

Core shape:

```text
Tailnet users/devices
  -> Tailscale MagicDNS or private split DNS
  -> Tailscale Kubernetes Operator
  -> private Kubernetes Ingress / LoadBalancer
  -> comms services
```

Candidate stack:

- **Mattermost + Calls** for fastest usable Discord/Slack-like private community.
- **Matrix / Element** for open-protocol private messaging, E2EE rooms, and future bridges.
- **Zulip** if structured async discussion matters more than Discord-like UX.
- **Mumble** for lightweight persistent voice rooms.
- **LiveKit or Jitsi** for richer WebRTC audio/video/meetings.
- **Authentik or Keycloak** for SSO/OIDC/MFA.
- **Postgres / Redis / MinIO**, plus backups.
- **cert-manager + DNS-01** for valid TLS without public HTTP ingress.

Preferred deployment pattern: expose a single private ingress controller through Tailscale, then route internally to `chat`, `matrix`, `element`, `voice`, and `auth` services. Keep no public ingress by default; use Tailscale ACLs plus app-layer auth.

MVP path: start with **Mattermost + Postgres + Calls** behind Tailscale-only ingress, add backups, optionally add Authentik, then add Matrix/Element and Mumble/LiveKit/Jitsi as needed.

Key tradeoffs to revisit: Matrix federation needs public reachability unless disabled/limited; private-only services may complicate mobile push; voice/video works well if all users are on Tailscale but guests need a separate exposure model; choose Matrix `server_name` carefully up front.
