v0.2.0

ConsoleChat v0.2.0 – New TUI, better backend, improved tooling

Highlights

• Brand-new component-based terminal UI with clear modes (Home, Login, Join, Chat, Settings, Raw Settings) and Vim-style Insert/Normal input for chat and config editing.
• Reworked Rust TUI runtime with a dedicated event loop, FPS counter, error popups, and smoother async networking.
• Backend updated to sqlmodel-based models, extended message types (including encrypted variants), and improved Docker/README for easier setup.
• Modern CI setup (Rust + Python), Dependabot, and GitHub issue templates to streamline contributions and maintenance.

New

• Introduced a modular component system for the TUI (Home, Login, Join, Chat, Settings, RawSettings), driven by a central App with Mode and Action enums.
• Added Vim-like input handling to the chat input and raw settings editor (Insert/Normal modes, navigation, enter-to-send/store, etc.).
• Implemented a new Tui runtime that:
  • Manages tick and frame rates.
  • Handles key, mouse, resize, and render events asynchronously.
  • Supports raw mode, alternate screen, mouse, and bracketed paste.
• Added UI components:
  • Home menu with keyboard navigation (j/k, enter) for Join, Login, Settings, Raw Settings, Exit.
  • Chat view with message list and message selection.
  • Join and Login forms for room selection and authentication.
  • ErrorDisplay popup with queued errors and timeout.
  • FpsCounter displaying ticks/sec and FPS.

Backend and protocol

• Migrated database layer from SQLAlchemy-style models to sqlmodel with DBUser / DBPublicUser as first-class models and centralized connection initialization.
• Simplified and extended datamodels:
  • New MessageType values for plain/encrypted text, join/leave, system, key request/key.
  • Updated ClientMessage, ServerMessage, and UserStatus to match the new schema.
• Improved backend Docker and docs:
  • Clearer backend README with project structure, env variables, SSL/nginx setup, and docker compose up --build -d instructions.
  • Adjusted Dockerfile to better support configurable ports and FastAPI startup.

Networking and encryption

• Replaced the previous network code with a singleton-style Client that holds auth token, room, symmetric key, and keypair, plus:
  • Async auth and token handling.
  • Room join/leave helpers.
  • Background listen worker with cancellation token.
• Defined clearer NetworkError types and mappings to UI errors.
• Laid groundwork for end-to-end encryption by adding key exchange and symmetric encryption hooks in the message flow.

Tooling and CI

• Split CI into dedicated workflows:
  • Rust: tests, cargo fmt, clippy, docs (including private items/examples) for console-chat.
  • Python: black, pylint, pyright, and pytest for the backend.
• Added Dependabot configuration for Cargo and pip dependencies.
• Added GitHub issue templates for bug reports and feature requests.

Logging, errors, and stability

• Introduced a new logging subsystem using tracing + color-eyre with:
  • Per-run log files (plain JSON and ANSI) in the data directory, with basic rotation via timestamped filenames.
  • Configurable log level via env vars.
• Added a custom panic handler that:
  • Clears/rotates logs on panic.
  • Produces human-readable crash reports (with optional human-panic in debug).

Project structure

• console-chat is now the primary TUI client with the new architecture.
• The previous implementation has been moved to old-console-chat and is considered deprecated.

Breaking changes

• Old screens and widgets modules have been removed in favor of components and Action/Mode; any external code referencing the old layout must be updated.
• Datamodel and message type changes mean older clients may not interoperate correctly with the updated backend without adjustments.

---

Full Changelog: v0.1.0-alpha...v0.2.0

v0.1.0

console-chat — Release v0.1.0 (Initial public release)

Release date: 2025-10-24
Maintainer: thetechnicker
Repository: https://github.com/thetechnicker/console-chat

Overview

v0.1.0 is the initial public release of console-chat. This release is a two-part application:

• Backend: a Python FastAPI service that implements auth, user management, and a pub/sub message transport (valkey).
• Frontend: a Rust-based terminal user interface (TUI) client that connects to the backend via HTTP/streaming endpoints and presents a keyboard-driven UI.

This release focuses on a minimal, working local/LAN chat prototype: authenticated sessions (JWT), publishing/subscribing to rooms via a fast pub/sub store, and a responsive terminal TUI.

Architecture

• Backend (Python)

  • FastAPI application (backend/app/main.py).
  • Uses JWT access tokens for session tokens returned by /auth.
  • Uses valkey (Redis-like) for pub/sub and StreamingResponse for long-poll/streaming room subscriptions.
  • Persists user records in PostgreSQL (SQLAlchemy models in backend/app/database.py).
  • Pydantic models in backend/app/datamodel.py mirror the API message shapes.
  • Provided Dockerfile and docker-compose for local development (postgres, valkey, chat-server).

• Frontend (Rust)

  • Terminal UI implemented with ratatui and tui_input (console-chat/src/*).
  • Event loop and input handling are implemented with tokio + crossterm event stream.
  • UI screens: Login, Home, Chat (console-chat/src/screens/*).
  • Widgets: InputWidget and Button with focus/activation state (console-chat/src/widgets/*).
  • Network client: reqwest-based ApiClient handling /auth, POST /room/{room} (send), and GET /room/{room} (listen/stream).
  • Network errors are typed and propagated into the UI via an internal Event system.

Highlights / Key features

• Correct two-part split: Python backend + Rust TUI frontend.
• Backend:
  • /auth endpoint that issues JWT tokens (supports anonymous login or username/password).
  • /room/{room} POST to publish client messages (authenticated).
  • /room/{room} GET returns a StreamingResponse that listens on a valkey pubsub channel and yields messages / timeout events.
  • /users/register endpoint and /users/status; /valkey/status health check.
  • PostgreSQL models for users and public user info; valkey connection pool for pub/sub.
  • Dockerfile and docker-compose.yml for dev environment (postgres + valkey + chat-server).
• Frontend:
  • Full TUI with login screen, home screen (room selection), and chat screen with scrollback and message listing.
  • Keyboard-driven navigation: Tab/BackTab to move focus, Enter to send, Esc to unfocus, Ctrl+C quits.
  • Networking: ApiClient obtains bearer token from /auth, posts messages to /room/{room}, and listens to the streaming room feed. The client parses streaming JSON chunks and forwards messages into the app event stream.
  • UI error popup with automatic timeout and an error queue.
  • Alternate-row styling for chat messages, cursor positioning for inputs, and focus management across widgets.
  • File-based logging (terminal-chat.log) via fern.

Behavior and implementation notes

• Auth:
  • The client calls POST /auth; server returns a UserStatus containing a token (JWT) and TTL. Tokens are required for other endpoints via HTTP Bearer.
  • /auth supports anonymous logins (no username/no password) and username-only flows. Password login will validate against the DB if present.
• Messaging transport:
  • Backend publishes messages to a valkey channel (room name). GET /room/{room} subscribes and returns a StreamingResponse of raw JSON messages (or a timeout event).
  • Client listen uses reqwest.get(...).bytes_stream() to process streaming messages chunk-by-chunk and forward parsed messages as NetworkEvent::Message.
  • After the streaming connection closes or times out, the client signals a reconnect request to the app.
• Data models:
  • Pydantic models (backend) and serde models (frontend) closely mirror each other: MessageType (TEXT/JOIN/LEAVE/SYSTEM), BaseMessage, ClientMessage, ServerMessage, public user info.
  • Backend enforces that non-system ServerMessage must include user info (validator).
• Persistence and state:
  • Users are stored in Postgres via SQLAlchemy models (DBUser, DBPublicUser). Database initialization is handled by Base.metadata.create_all(engine).
  • The backend returns TTL in auth; client stores bearer token in-memory (ApiClient.bearer_token).
• Dev and deployment:
  • backend/Dockerfile builds a Python 3.12 container and runs uvicorn app.main:app.
  • backend/docker-compose.yml includes services: postgres, valkey, chat-server for local integration testing.
  • The Rust client is a terminal app built with cargo (console-chat/).

Known limitations and caveats

• No TLS by default. Server issues JWTs over HTTP; in production you must use HTTPS/terminate TLS in front of FastAPI.
• Authentication/authorization is minimal: tokens are JWTs but there's no multi-factor auth or additional identity checks.
• Registration endpoint (/users/register) behavior differs from typical flows (it depends on current BetterUser obtained from token); review flow before production use.
• There is no built-in message encryption or E2E protection — message transport relies on valkey and HTTP.
• Single shared room subscription model in this release — no per-user direct messaging or multi-channel UI beyond selecting a single room.
• Error handling and automated tests are limited; cross-platform Windows terminal behavior is lightly tested (primary focus: Unix-like terminals).
• No packaged binaries for the TUI client — building from source is required.

Quick start (development)

Prerequisites:

• Docker & docker-compose (for full stack), or Python 3.12 + PostgreSQL + valkey + Rust toolchain for the client.

Start backend (docker-compose):

1. cd backend
2. Copy or create a .env with POSTGRES_*, DEV_API_KEY (optional), SECRET, etc.
3. docker compose up --build

Or run backend directly:

• python -m uvicorn app.main:app --host 0.0.0.0 --port 8000

Run the Rust TUI client (local):

1. cd console-chat
2. cargo run --release
   (If you need to point the client at a custom server URL, modify App::new call or run with an environment variable / change in main prior to building.)

API endpoints (selected)

• POST /auth — authenticate (username/password optional) — returns token TTL
• GET /room/{room} — streaming subscribe for room messages (listen_seconds query param)
• POST /room/{room} — send message to room (authenticated)
• GET /users/status — return current BetterUser (requires token)
• POST /users/register— register a user (see server code; flow has caveats)
• GET /valkey/status — valkey health check

What changed in v0.1.0

• Added Python FastAPI backend with:
  • JWT-based /auth and token handling.
  • valkey-based pub/sub messaging and a streaming GET /room/{room}.
  • Basic user persistence (Postgres + SQLAlchemy).
  • Register, user status, and valkey status endpoints.
  • Dockerfile and docker-compose for local dev.
• Added Rust TUI client with:
  • Login, Home (room selection), and Chat screens.
  • Input and Button widgets with focus and keyboard navigation.
  • reqwest-based ApiClient supporting auth, send, and streaming listen.
  • Event system to deliver network events into the UI and automatic reconnect triggers.
  • File logging and UI error popups.

Upgrade / migration notes

• Back up any data from Postgres or valkey before upgrading the backend.
• JWT secret (SECRET env) should be changed from defaults before production.
• Future releases will likely introduce TLS/HTTPS and improved auth/registration flows — keep your .env and DB backups.

Contributing

• Issues and PRs welcome. The repository contains both backend/ (Python) and console-chat/ (Rust) code — please target the appropriate subproject for fixes or features.
• For backend work: run tests and linting in the backend virtualenv, use docker-compose to test integration with postgres/valkey.
• For frontend work: cargo fmt, cargo clippy, and run the TUI in a compatible terminal.

Changelog

• v0.1.0 — Initial public release: FastAPI backend (Python) + Rust TUI frontend, streaming room transport (valkey), basic auth, room publish/subscribe, and local dev Docker setup.