telegram-chat-history-persistencelisted

## When to Use Invoke when: - The Telegram bot fails to recall a message from a prior session - Designing or revisiting how chat history is persisted and injected - Evaluating trade-offs between history storage approaches ## Approaches (Evaluated) | # | Approach | Pros | Cons | |---|----------|------|------| | 1 | Full transcript injection | Lossless, zero deps | Context window explodes | | 2 | Sliding window / rolling buffer | Bounded tokens | Fails for anything outside the window | | 3 | **LLM-summarized history** ✓ | Bounded, captures gist, handles long gaps | Slight losiness; one async LLM call per session | | 4 | SQLite store | Queryable, durable, no external deps | Still needs retrieval strategy on top | | 5 | RAG over chat history | Solves "10 hours ago" references | Needs embedding model (e.g. local ollama) | | 6 | MemPalace | Zero new infra | Gateway shell can't call MCP directly; needs glue | | 7 | Mem0 / Zep managed | Production-ready | Data leaves machine, external cost | | 8 | Long-context model injection | No retrieval logic | Expensive, slow, still has a ceiling | ## Recommended Approach: LLM Summary + SQLite + Last-N Raw Turns **Implementation steps:** 1. **Log every exchange** to a local JSONL file: `{timestamp, sender, text, session_id}` 2. **On session close**, run an async Claude call to summarize the session and write it to SQLite (`session_summaries` table: `session_id`, `closed_at`, `summary_text`) 3. **On session start**, the gateway shell script