6.5 KiB
6.5 KiB
🗺️ Chat Switchboard — Roadmap
See also:
- ARCHITECTURE.md — Core services design (Notes, KBs, Tasks, Channels, Embeddings)
- EXTENSIONS.md — Extension system spec (Browser/Starlark/Sidecar tiers, tools, surfaces)
Current State: v0.5.4
✅ Done
Backend (Go)
- PostgreSQL schema + auto-migrations (go:embed, startup)
- JWT auth with refresh token rotation
- Chat CRUD + message persistence
- Streaming completion proxy (OpenAI + Anthropic + Venice + OpenRouter)
- Per-user + global API config management
- Admin endpoints (users, providers, models, settings, stats)
- Rate limiting, error middleware, request logging
- Health check endpoint (includes schema_version)
- EventBus with WebSocket hub
- Provider capability system (known models, heuristic detection, resolution chain)
- Dynamic max_tokens resolution (no more hardcoded 4096)
- User + admin provider model listing with capabilities
Frontend (Vanilla JS)
- Collapsible sidebar with time-grouped chat history
- User menu flyout (Settings, Admin, Debug, Sign Out)
- Model selector with capability badges (output, context, tools, vision, thinking)
- Client-side known model table with backend overlay
- Streaming SSE display with smart scroll
- Full markdown rendering (marked.js + DOMPurify)
- Thinking block display (
<think>/<thinking>tags) - Settings modal (profile, chat prefs, provider management)
- Admin modal (users, providers, models with cap badges, settings, stats)
- Debug modal (console intercept, network log, state inspector)
- EventBus client with exponential backoff + max retries
- Export (Markdown, JSON, Text)
- Vendor libs with CDN fallback (SCIF-safe)
- 3-stage Dockerfile (Go build → vendor download → nginx)
CI/CD (Gitea Actions)
- Three-env pipeline (dev/test/prod)
- Dev: upgrade test → schema validate → wipe → fresh install test
- Backend auto-migrates on startup (no CI migration step)
- Shared PG safety (_dev suffix guard on wipe)
- Post-deploy schema verification via /api/v1/health
Architecture Design (v0.5.4)
- ARCHITECTURE.md: core services spec (13 sections)
- EXTENSIONS.md: three-tier extension system spec
- Terminology: Roles, Teams, Channels, Message Tree, etc.
- "Everything is a channel" — chat is a channel with type:'direct'
- Conversation forking (message tree via parent_id)
- Auth strategy (builtin/mTLS/OIDC)
- Classification banners (CSS custom props)
Implementation Phasing
See ARCHITECTURE.md §10 for the authoritative implementation sequence. Phases 1–8, from channel foundation through RBAC.
Phase 1: Real-Time Foundation
1.1 WebSocket Hub
Priority: HIGH — blocks Channels, typing indicators, live updates
- WebSocket upgrade endpoint (
/ws) - Connection manager (register, unregister, broadcast)
- Room-based pub/sub (per-chat, per-channel, global)
- JWT auth on WebSocket handshake
- Heartbeat / ping-pong keepalive
- Reconnection handling (frontend)
- Message types:
chat.message,chat.typing,user.presence,system.notify
1.2 Live Chat Updates
- New messages pushed via WebSocket (not just SSE streaming)
- Typing indicators
- Chat list updates when other sessions create/delete chats
- Online user presence
Phase 2: Channels
2.1 Backend
- Channel model (name, description, type: public/private/DM, creator)
- Membership model (user_id, channel_id, role: owner/member)
- Channel messages (extends message model with channel_id)
- CRUD endpoints:
/api/v1/channels,/api/v1/channels/:id/messages - @mention parsing — users and AI models
- AI response triggered by @model-name mentions
- WebSocket broadcast per channel room
2.2 Frontend
- Channels section in sidebar (below chats, collapsible)
- Channel creation modal (name, description, public/private)
- Member management (invite, remove, role change)
- Message display with user avatars and @mention highlighting
- AI responses inline with user messages
- Unread count badges
Phase 3: Plugin System
3.1 Architecture (see discussion below)
- Plugin manifest format (
plugin.json) - Plugin lifecycle (install, enable, disable, uninstall)
- Plugin storage (per-plugin isolated DB namespace or key-value)
- Hook system (pre-completion, post-completion, on-message, on-channel-message)
- Admin UI for plugin management (install, configure, enable/disable)
- Plugin API (what plugins can access: messages, user context, settings)
3.2 Built-in Plugin: Web Search
- Tool-use integration in completion flow
- Search provider abstraction (DuckDuckGo, SearXNG, Brave)
- Results injected into context
3.3 Built-in Plugin: Token Counter
- Per-message token estimation
- Per-chat cost tracking
- Provider-specific pricing data
Phase 4: Notes & Knowledge Base
4.1 Notes
- Note model (title, content, folder, tags)
- CRUD endpoints
- Folder organization
- Full-text search (PostgreSQL
tsvector) - Markdown editor in frontend
- Link notes to chats
4.2 RAG (Retrieval Augmented Generation)
- Document upload (PDF, DOCX, TXT, MD)
- Chunking strategies (recursive, semantic)
- Embedding generation (OpenAI, local models)
- pgvector storage and similarity search
- Context injection in completion flow
- Per-KB toggle in chat settings
Phase 5: Polish
- Chat search / filter in sidebar
- Message editing
- Chat folders / pinning
- Bulk chat operations
- Keyboard shortcuts (Ctrl+K command palette)
- PWA manifest + offline shell
- Performance: lazy load chat history, virtual scroll for long chats
Future
- Desktop app (Tauri)
- Smart model routing (cost/quality/latency auto-selection)
- Workflow builder (visual DAG for chaining models + tools)
- Plugin marketplace
- SSO/SAML
- Audit logging
- Multi-tenant SaaS mode
Plugin / Extension Architecture
Moved to dedicated documents:
- EXTENSIONS.md — Full extension system spec with three tiers (Browser JS, Starlark sandbox, Sidecar containers), manifest format, browser tool bridge, surface/mode system, and implementation roadmap.
- ARCHITECTURE.md — Core backend services that extensions build on: Notes, Knowledge Bases, Tasks, Channels, Embeddings, and Folders/Projects. Includes data models, sequencing, and admin controls.