[Enhancement] Per-user long-term memory and conversation summarization for personalized answers

[zeemscript]

Summary

The assistant has amnesia. It has no concept of a user — only anonymous chat_id sessions — so a student who has spent weeks asking about tajweed at a beginner level starts from zero in every new conversation, and a long conversation loses its earliest (often most important) context the moment any history cap lands. This issue adds a personalization memory layer: an optional user_id on chat requests, a per-user long-term memory (knowledge level, madhhab preference, preferred language, topics studied, standing facts the user shared) that is extracted from conversations and injected into future sessions, and summarization-based compaction that folds old turns into a running summary instead of discarding them. This is what turns a stateless Q&A endpoint into a tutor that knows its student.

Current state

• There is no user identity anywhere in the service: ChatRequest (main.py, lines 79–82) carries prompt, chat_id, and context only. Two conversations by the same person are unrelatable.
• Sessions live in the in-process active_chats dict (line 54), keyed by chat_id, and are wiped on every restart. Issue [Enhancement] Persist chat sessions instead of holding them in process memory #3 covers moving session history to an external store (Redis); it does not add user identity or any cross-session memory.
• Issue [Enhancement] Cap conversation history with a token budget to prevent unbounded prompt growth #13 covers capping history with a token budget by dropping oldest turn pairs; its body names summarization-based compaction an optional stretch goal and explicitly does not require it. Nothing anywhere extracts durable facts about the user.
• The DeenBridge backend (dnb-backend) has authenticated users, so the frontend can supply a stable user identifier — the AI service just never asks for one.

What to build

1. user_id on requests — add user_id: Optional[str] to ChatRequest. No user_id → exactly today's stateless behavior; memory features activate only when it is present. Treat it as an opaque string (auth/API-key work is issue [Enhancement] Add service API-key auth and rate limiting to protect the Gemini quota #9's scope, not this one).
2. Memory store — a memory.py module behind a small interface with two backends: the same Redis the session-persistence issue ([Enhancement] Persist chat sessions instead of holding them in process memory #3) targets (REDIS_URL), and an in-memory/dict fallback for local dev and tests. Schema: a structured profile (knowledge_level, madhhab, language, topics_studied with recency, plus a bounded list of free-form remembered facts like "is a new convert", "studying for an exam"), each entry carrying a timestamp. Cap the profile size (e.g. max N facts, LRU/oldest-out) so it cannot grow unboundedly.
3. Memory extraction — after a conversation turn completes (or every K turns — justify the trigger), run a cheap structured-output Gemini call over the recent exchange that proposes profile updates ("user said they follow the Maliki school", "asked third question about inheritance — add topic"). Apply updates through validation (e.g. madhhab must be a known value — reuse normalization from the madhhab-awareness issue if both land). Run extraction outside the request's critical path (background task via FastAPI's BackgroundTasks or equivalent) so chat latency is unaffected.
4. Memory injection — when a session starts (or on each request for stateless-per-request designs), render the profile into a compact, clearly delimited context block ("Known about this student: …") appended to the system context — never into the user turn, and written so it composes with the injection-hardening work in [Bug] Islamic system prompt is skipped for plain requests and easily overridden by prompt injection #5 (data, not instructions).
5. Summarization compaction — implement the compaction [Enhancement] Cap conversation history with a token budget to prevent unbounded prompt growth #13 left as a stretch goal: when a conversation exceeds the history budget, summarize the turns being evicted into a running conversation summary (one model call, structured to preserve open questions, established facts, and the user's goal) and keep that summary pinned at the head of the context. Coordinate directly with [Enhancement] Cap conversation history with a token budget to prevent unbounded prompt growth #13's assignee if both are in flight — this issue owns "summarize", that one owns "budget + truncate", and the seam is the eviction hook.
6. Privacy controls — memory is personal data about a person's religious life; treat it accordingly: GET /memory/{user_id} returns the stored profile (transparency), DELETE /memory/{user_id} erases it completely, a remember: bool = True request flag lets a caller mark a conversation as do-not-learn, and profile entries carry TTL (env-configurable, e.g. MEMORY_TTL_DAYS). Never log profile contents at INFO level.
7. Tests — extraction-application logic against a fake store and mocked model (proposed updates validated, capped, timestamped); injection rendering; compaction seam (summary replaces evicted turns and is preserved thereafter); privacy endpoints (get/delete/opt-out). All offline; CI stays green.

Acceptance criteria

• Requests without user_id behave byte-for-byte like today; with user_id, a fact established in one conversation (e.g. "I'm a beginner") measurably shapes a new conversation's answer (manually demonstrated in the PR, plus injected-context unit assertions).
• Memory extraction runs off the critical path — /chat latency shows no added model call in the request/response timeline.
• The profile is bounded (size cap + TTL) and every entry is timestamped; validation rejects malformed extraction proposals.
• A conversation driven past the history budget retains earlier established facts via the pinned summary — the model correctly answers a question about something said before the eviction point.
• GET/DELETE memory endpoints work; remember: false conversations leave no trace; profile contents never appear in INFO logs.
• Redis and in-memory backends pass the same test suite; store selection via REDIS_URL presence is documented in the README env-var table.
• CI stays green with new modules linted and tested.

Pointers

• main.py — ChatRequest (lines 79–82), active_chats (line 54), the /chat handler (lines 118–184), DELETE /chat/{chat_id} (lines 187–198).
• Boundary map (important — three neighboring issues): [Enhancement] Persist chat sessions instead of holding them in process memory #3 = where session history lives (share its Redis and key-naming conventions); [Enhancement] Cap conversation history with a token budget to prevent unbounded prompt growth #13 = the token budget and truncation mechanism (this issue plugs summarization into its eviction point); [Enhancement] Personalized learning-path recommendation endpoint with validated structured output #33 = a separate learning-path endpoint fed by explicit request data, not chat memory (if both land, the profile is a natural input — leave a hook, don't integrate). Do not re-implement any of those three.
• [Enhancement] Semantic response cache with embedding-similarity matching for repeated questions #27 (semantic response cache): personalized answers must not be served from a shared cache — if both land, memory-influenced responses need a cache-bypass or per-user cache key; flag it in the PR.
• CI (.github/workflows/ci.yml) lints only main.py and has no pytest step — extend both. PRs target the dev branch (see CONTRIBUTING.md).

Difficulty

High — background extraction with validation, a two-backend store, compaction that must interlock cleanly with a separately-assigned truncation issue, personalization that respects prompt-injection boundaries, and privacy endpoints — all with a hard requirement that anonymous traffic is completely unaffected.

---

🏆 GrantFox OSS — Official Campaign | FWC26. Apply for this issue through the GrantFox campaign page. The maintainer assigns one contributor before work starts; unassigned PRs may not be reviewed. PRs target the dev branch. Quality bar: CI must stay green.

💬 Questions or need help? Reach the maintainers and other contributors on the DeenBridge Telegram: https://t.me/+nst9lXNj1wc4ZDE0

[JesseJohn7]

Hello, I’ve gone through the requirements and I’m confident I can implement a proper solution that matches the acceptance criteria. Kindly assign this issue to me.

[Joyful12-tech]

Hello Maintainer,

I'd like to work on this issue. I'll implement the personalization memory layer, add tests, and submit a PR within 2 days.

Thank you!

[shogun444]

Hi, I’d like to work on this issue.

I have experience building full-stack applications with AI integrations, persistent data layers, authentication, and structured LLM workflows, and I’m interested in implementing the long-term memory layer as a clean extension of the existing chat architecture.

My approach would be to introduce the optional user_id without changing anonymous-session behavior, then build a bounded memory abstraction with interchangeable Redis and in-memory backends. I’ll implement validated structured memory extraction outside the /chat critical path, safely inject remembered context as data rather than instructions, and add summarization-based compaction at the history-eviction seam without duplicating the work owned by #3 or #13.

I’ll also cover the privacy requirements explicitly: TTL-based retention, bounded profiles, remember:false opt-out, GET/DELETE memory controls, and ensuring personal profile contents are never emitted through INFO logs.

I’ll coordinate the implementation around the neighboring session-persistence and token-budget work so the changes remain modular and avoid conflicting architecture. Tests will cover both storage backends, extraction validation, profile limits, cross-session memory injection, summarization persistence, opt-out/deletion, and anonymous-user backward compatibility.

I can start immediately and will keep the implementation scoped to the issue’s acceptance criteria.

Portfolio:
https://portfolio-amber-one-v8ggyhsjyr.vercel.app/

ETA -1 day

[grantfox-oss]

🦊 GrantFox — @shogun444 has been assigned to this issue as part of the Official Campaign | FWC26 campaign!

Next steps:

1. Open a Pull Request referencing this issue (e.g., Closes #41)
2. Your PR will be reviewed by the Deen-Bridge maintainers

Good luck! Track your progress on GrantFox.