| 1 | # 🤖 Eleven's memory — remembered by the bot, owned by the member |
| 2 | |
| 3 | *"What's your role?" — asked for the third time this week.* Without memory, |
| 4 | an AI helper's entire knowledge of a member is the last ~30 messages of the |
| 5 | current thread: every DM is groundhog day. This document describes the |
| 6 | memory that fixes it, and the property that makes it acceptable: **nothing |
| 7 | the bot remembers is ever invisible, uneditable, or unerasable.** |
| 8 | |
| 9 | ## What it is |
| 10 | |
| 11 | A small set of durable facts (max 24, ≤ 280 chars each) an AI helper keeps |
| 12 | about a member — role, standing preferences, anything the member asked it to |
| 13 | keep. Two halves, one store: |
| 14 | |
| 15 | - **The bot's half** (`internal/bot/memory.go`): `remember` / `forget` tools |
| 16 | offered to the conversational brain in DMs only. What's remembered rides the |
| 17 | DM's system context (after the cache breakpoint, like a bot-home thread's |
| 18 | charter note), so the helper simply *knows* — and it's told to never claim a |
| 19 | memory that isn't in the list. |
| 20 | - **The member's half** (`web/static/apps/memory.js`): the **scratchpad** — a |
| 21 | command panel opened by `/memory`, the chat's ⋮ menu → Memory, or the chip |
| 22 | every write attaches. It shows every fact and lets the member edit any of |
| 23 | them, add their own, delete one, or erase everything. Memory the member |
| 24 | can't inspect is creepy; memory they can is a feature. |
| 25 | |
| 26 | ## Where it lives (the trust model) |
| 27 | |
| 28 | The `"memory"` slot of the **DM thread's state store** (`miniapps.go` — |
| 29 | `GET/PUT /api/threads/{id}/state`, optimistic versioning), encrypted under |
| 30 | the **DM's thread key**. That one choice does the heavy lifting: |
| 31 | |
| 32 | - **E2EE to exactly two parties.** Only the member and that bot hold the DM |
| 33 | key. Not the instance key (which every member holds) — things learned in a |
| 34 | private conversation stay in that conversation's trust class. The server |
| 35 | stores ciphertext, as ever. |
| 36 | - **Per relationship.** Your memory with Eleven is not your memory with |
| 37 | Claude — each DM has its own slot under its own key. Retiring a helper (or |
| 38 | ending the DM) strands nothing anywhere else. |
| 39 | - **No new server surface.** The slot machinery, versioning, and member |
| 40 | gating already existed for app-state snapshots; memory is one more slot |
| 41 | (`"memory"`, distinct from `"apps"`, so the two never contend). |
| 42 | |
| 43 | Writes are whole-blob at the version read; a concurrent write 409s and the |
| 44 | loser reloads (the sidecar retries its op against the fresh copy; the |
| 45 | scratchpad shows the latest and the member redoes the edit). Both readers |
| 46 | re-clamp whatever they read (`clampMemory` in Go, `sanitizeMemory` on the |
| 47 | web — unsigned shared slot, so read-side clamping is the invariant). |
| 48 | |
| 49 | ## Transparency rules |
| 50 | |
| 51 | - **Every write announces itself.** The sidecar — never the model — appends |
| 52 | an `open_memory` chip to any reply whose turn performed a remember/forget |
| 53 | ("✍️ Noted — see what I remember"). No silent writes. |
| 54 | - **DM-only.** The tools and the recall exist only in the DM where the memory |
| 55 | lives. Group-Eleven never reads DM-derived memory — whether it ever should |
| 56 | is a deliberate future decision, not a default. |
| 57 | - **Hygiene in the tool contract.** The `remember` description forbids |
| 58 | secrets (passwords, keys, codes) and sensitive details (health, finances, |
| 59 | other people's private business) unless the member explicitly asks, and the |
| 60 | model is told to store one short third-person fact per call. |
| 61 | - **Bounded.** 24 facts × 280 chars keeps the whole memory a few hundred |
| 62 | tokens of context and one small ciphertext blob. |
| 63 | |
| 64 | ## Scope |
| 65 | |
| 66 | Web-first (stated): the scratchpad is a web command panel; native renders AI |
| 67 | DMs through the webview surfaces today. The `open_memory` chip type is |
| 68 | whitelisted on web (`ui.js CHIP_TYPES`) and unknown to native clients, which |
| 69 | drop unrecognised chips — the reply text still reads fine. Natural next |
| 70 | rungs: the panel's `side` placement everywhere (#816 ships it), surfacing |
| 71 | memory in the member's bot-home threads, and a deliberate design for whether |
| 72 | any of it may inform group replies. |
| 73 | |
amadan