MystenLabs / MystenLabs/MemWal
Dashboard has no way to browse or audit what agents stored — recall-only visibility
Nobody has claimed this yet.
- Dominant language
- TypeScript
- Stars
- 107
- Forks
- 37
- Avg merge
- 3d 12h
- Merged PRs (30d)
- 86
Description
I spent tonight wiring an agent onto @mysten-incubation/memwal and @mysten-incubation/memwal-mcp, and the moment I tried to answer "what exactly did my agents store?" I hit a wall: holding a valid delegate key and account ID, there is no way to see stored content except guessing. The manage-your-memory guide states this as designed behavior — "You do not browse memories by name or folder. You search them by meaning."
Semantic recall is good retrieval, but it is not an audit tool. Recall only surfaces entries that happen to be nearest neighbors of whatever query I type, so anything I phrase wrong stays invisible. As far as I can find, the dashboard's only content preview lives inside the irreversible delete flow, which makes today's UX for "show me my data" literally: start deleting. There is no namespace list, no per-namespace content view, and no search-over-my-own-memories UI beyond running recall queries.
My actual audit procedure tonight was: guess plausible namespace strings and call restore(ns) per guess, reading the echoed total to learn whether a string existed at all. That only works if I guess right, and even on a hit it told me nothing about content — I then had to fire blind recall queries into each discovered namespace. An agent inheriting my credentials cannot enumerate its own memory either.
What would fix it: a read-only Memory Explorer tab in the dashboard — left rail listing the owner's namespaces, then per-namespace entries showing createdAt, a decrypted text preview, and the blob ID linked to its Walrus object. The delete flow already previews decrypted content server-side, so relayer endpoints capable of this exist today; they just aren't wired into a browsing view. Read-only keeps the permission model untouched.
Related to MystenLabs/MemWal#723, which reports the same visibility gap from the symptom side (dashboard shows no memories or blob count for an account holding 185 blobs).
Environment
- Client: memwal-mcp via
npx -y @mysten-incubation/memwal-mcp; TypeScript SDK@mysten-incubation/memwal - Relayer: version 0.1.0, apiVersion 1.0.0, mode production (mainnet)
- Node v22.14.0, Linux
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by tracing the dashboard's existing delete flow and the relayer endpoints that provide its decrypted content preview. Define the read-only explorer around an owner's namespace list, per-namespace entries with createdAt and text previews, and blob IDs linked to Walrus objects; done means these memories can be audited without deletion or guessed recall queries.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- typescript
- Domain
- api, frontend
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100