# 🤖 Eleven's memory — remembered by the bot, owned by the member

*"What's your role?" — asked for the third time this week.* Without memory,
an AI helper's entire knowledge of a member is the last ~30 messages of the
current thread: every DM is groundhog day. This document describes the
memory that fixes it, and the property that makes it acceptable: **nothing
the bot remembers is ever invisible, uneditable, or unerasable.**

## What it is

A small set of durable facts (max 24, ≤ 280 chars each) an AI helper keeps
about a member — role, standing preferences, anything the member asked it to
keep. Two halves, one store:

- **The bot's half** (`internal/bot/memory.go`): `remember` / `forget` tools
  offered to the conversational brain in DMs only. What's remembered rides the
  DM's system context (after the cache breakpoint, like a bot-home thread's
  charter note), so the helper simply *knows* — and it's told to never claim a
  memory that isn't in the list.
- **The member's half** (`web/static/apps/memory.js`): the **scratchpad** — a
  command panel opened by `/memory`, the chat's ⋮ menu → Memory, or the chip
  every write attaches. It shows every fact and lets the member edit any of
  them, add their own, delete one, or erase everything. Memory the member
  can't inspect is creepy; memory they can is a feature.

## Where it lives (the trust model)

The `"memory"` slot of the **DM thread's state store** (`miniapps.go` —
`GET/PUT /api/threads/{id}/state`, optimistic versioning), encrypted under
the **DM's thread key**. That one choice does the heavy lifting:

- **E2EE to exactly two parties.** Only the member and that bot hold the DM
  key. Not the instance key (which every member holds) — things learned in a
  private conversation stay in that conversation's trust class. The server
  stores ciphertext, as ever.
- **Per relationship.** Your memory with Eleven is not your memory with
  Claude — each DM has its own slot under its own key. Retiring a helper (or
  ending the DM) strands nothing anywhere else.
- **No new server surface.** The slot machinery, versioning, and member
  gating already existed for app-state snapshots; memory is one more slot
  (`"memory"`, distinct from `"apps"`, so the two never contend).

Writes are whole-blob at the version read; a concurrent write 409s and the
loser reloads (the sidecar retries its op against the fresh copy; the
scratchpad shows the latest and the member redoes the edit). Both readers
re-clamp whatever they read (`clampMemory` in Go, `sanitizeMemory` on the
web — unsigned shared slot, so read-side clamping is the invariant).

## Transparency rules

- **Every write announces itself.** The sidecar — never the model — appends
  an `open_memory` chip to any reply whose turn performed a remember/forget
  ("✍️ Noted — see what I remember"). No silent writes.
- **DM-only.** The tools and the recall exist only in the DM where the memory
  lives. Group-Eleven never reads DM-derived memory — whether it ever should
  is a deliberate future decision, not a default.
- **Hygiene in the tool contract.** The `remember` description forbids
  secrets (passwords, keys, codes) and sensitive details (health, finances,
  other people's private business) unless the member explicitly asks, and the
  model is told to store one short third-person fact per call.
- **Bounded.** 24 facts × 280 chars keeps the whole memory a few hundred
  tokens of context and one small ciphertext blob.

## Scope

Web-first (stated): the scratchpad is a web command panel; native renders AI
DMs through the webview surfaces today. The `open_memory` chip type is
whitelisted on web (`ui.js CHIP_TYPES`) and unknown to native clients, which
drop unrecognised chips — the reply text still reads fine. Natural next
rungs: the panel's `side` placement everywhere (#816 ships it), surfacing
memory in the member's bot-home threads, and a deliberate design for whether
any of it may inform group replies.