Updated: September 23, 2026

Roadmap: shipped milestones and the plans ahead

LetsChat is built plan by plan. This roadmap tracks what has shipped and the sequenced work ahead — each plan builds on the one before it. There are no fixed calendar dates; plans land in order as they're completed.

6

Plans shipped

1

Next up

8

Planned & later

How to read this

Shipped

Delivered and merged into main.

Next / Planned

Sequenced and scoped; later plans depend on earlier ones.

Optional / Deferred

Nice-to-have or idea-stage; may be skipped or scheduled later.

Shipped

Plan 1

Admin Control Panel & Identity

Shipped

An authoritative .NET auth backend and a browser-based admin panel.

  • core-api rebuilt on .NET 10 / ASP.NET Core Identity backed by PostgreSQL.
  • Email verification, per-IP rate limiting, and an admin approval workflow.
  • Razor admin panel — users, pending queue, system config, audit log — on a non-public listener.
  • Password reset end-to-end and production deployment cutover.

Plan 1.5

Space Permissions & Discovery

Shipped

Control over who can create spaces, and a public surface to find and join them.

  • Configurable space-creation policy, propagated into the chat-domain admin gate.
  • Opt-in discoverability with descriptions and topic tags; a Discover panel with search and tag filters.
  • Request-to-join flow for invite-only spaces — approve, decline, and re-request.
  • Per-owner anti-spam quota and instance-admin moderation (un-list any space).

Plan 1.6

Hosted Web Client & SpacetimeDB 2.5

Shipped

LetsChat in the browser, plus the realtime engine moved onto the current release line.

  • Hosted browser client at app.<domain> — single-tenant, auto-discovers its instance, no install.
  • Reliability-first WebSocket compression with automatic downgrade so a browser can never get stranded.
  • SpacetimeDB bumped 2.2 → 2.5 in lockstep (CLI, npm SDK, Rust crate, server image).
  • MinIO browser CORS, web join links, and a dismissable "also on desktop" prompt.

Identity Authority Inversion

core-api as the OIDC issuer

Shipped

One account, one permanent identity — derived rather than stored, and immune to database wipes.

  • core-api issues the realtime-database access token as an OIDC provider; the database verifies it against a published JWKS.
  • Identities derive deterministically from issuer + account, so they survive a wipe and never need relinking.
  • Retired the stale-token and relink bug class outright — tokens are minted on demand and never stored.
  • Breaking deploy: SPACETIME_OIDC_PRIVATE_KEY must be set before upgrading, or core-api refuses to start.

Plan 2, Part A

Durability & Cold Archive

Shipped

Nothing is lost: every message mirrored to PostgreSQL, and destructive migrations made survivable.

  • A .NET replication worker mirrors the chat domain into a PostgreSQL cold archive.
  • Destructive schema migrations become a safe wipe-and-rebuild from the archive.
  • Scheduled backups of all data, wired into the production compose stack.
  • Part B (evicting cold history from the hot set to cap server RAM) remains ahead.

v1.0

1.0 Release

Shipped

The first stable release — no half-finished surfaces left in the UI, and a deployment you can upgrade and roll back.

  • Pinned messages and in-channel message search — the last placeholder buttons are now live features.
  • Voice presence made server-owned: presence rows are connection-scoped and swept on disconnect, ending the join/leave desync.
  • The realtime module owns id allocation, so rebuilding from the cold archive can no longer collide with auto-increment.
  • Production images pinned by LETSCHAT_VERSION with immutable version and commit tags, published for amd64 and arm64, plus a documented upgrade/rollback runbook.

Plans ahead

Windows Code Signing

Signed Windows installers

P0Now~days
  • Sign the Windows build so SmartScreen/AV stop flagging LetsChat as malware.
  • Wire signing into the release CI; verify macOS notarization parity.
  • Highest-leverage adoption fix — done before storage tiering starts.

Plan 2, Part B

Storage Tiering — Eviction

P0Next~2 weeks
  • Keep only a bounded hot working set in SpacetimeDB to cap server RAM.
  • Serve older history from the cold archive on demand, transparently to the client.
  • Part A (durability: the archive mirror, safe rebuilds, scheduled backups) has shipped.
  • The client half already landed: clients sync a recent window and page older history back on scroll, so eviction only has to move rows, not change how they are read.

OTA Updates

Client & server auto-update

P1Planned~1–2 weeks
  • Tauri auto-updater for the desktop client over a signed update feed (builds on Windows code signing).
  • Automate the self-hosted server upgrade — today it's 100% manual (docker compose pull + spacetime publish); make it a one-command, safe update.
  • Staged rollout with version gating (already exposed in /.well-known); scheduled right after Plan 2.

Plan 3

Voice & Media Quality

P1Planned~2 weeks
  • Adaptive/simulcast video resolution that auto-downscales for weak connections.
  • Per-user and master audio volume controls.
  • Extend noise suppression to the web client (Krisp already ships on desktop).

Plan 4

Space Operations & Limits

P1PlannedMulti-week
  • Roll out and verify configurable daily, per-user stored, and installation stored limits on the shipped object registry.
  • Roll out and verify multipart uploads through Cloudflare Tunnel; add cross-restart upload continuation later.
  • Per-space role & access management (Discord-style roles) and space-specific storage quotas.
  • Drop the core-api↔SpacetimeDB admin-identity coupling; add operator-facing server logging.

Plan 5

Search & Group DMs

P2Planned~3 weeks
  • Full-text search across spaces and DMs — wiring up the currently-stubbed search UI.
  • Group direct messages.

Plan 6

Full UI Redesign

P2PlannedMulti-week
  • Deliberate ground-up visual redesign rather than incremental patches.
  • Profile popup cards, right-click context menus, and a custom window header rail.
  • UI and notification sounds.

Plan 7

End-to-End Encryption

P2PlannedMulti-week
  • Encrypt DMs first, then attachments and calls (LiveKit insertable streams), then spaces.
  • Per-conversation keys wrapped per device; all decryption happens on-device.
  • Key epochs rotate on membership change for re-readable, multi-device history.

Later / Ideas

Scheduled later or idea-stage

IdeaDeferredUnscheduled
  • Localisation (i18n) — agreed, scheduled for a later milestone.
  • Native mobile app, public integration API, and MCP integration.
  • Multi-instance client and an on-device offline cache.