flowise-memorysync

MemorySync Memory — a Flowise memory node with SEPARATE user and session dimensions: long-term memory follows the user across every chat, while each chat keeps its own transcript.

sdk/flowise/
  nodes/MemorySyncMemory/    ← the node (drops into flowise-components/dist/nodes)
  credentials/               ← the MemorySync API credential class
  src/                       ← fetch client + vendored Flowise interfaces
  tests/                     ← 21 vitest checks against a live mock MemorySync

Why this instead of the in-tree Mem0/Zep nodes?

Verified against Flowise 3.1.4 source:

| Behavior | Mem0 node (in-tree) | Zep nodes (in-tree) | MemorySync Memory | |---|---|---|---| | User vs session | ✗ conflated — the "Use Flowise Chat ID" toggle makes memory silently reset on every new chat | ✗ session is the ONLY dimension — no cross-chat user recall | ✅ both dimensions: userId (required) + per-chat session | | Default partition | ✗ ships user_id: flowise-default-user — everyone who keeps the default shares one memory | n/a | ✅ userId required at design time | | "Clear this chat" | ✗ calls Mem0 clear() — wipes the user's ENTIRE memory | session delete | ✅ deletes THIS session's rows only | | Recall in context | ✗ extracted facts cast as any onto an assistant-role message, double-stuffed with raw DB turns | summary only | ✅ ONE labeled block; a real SystemMessage in the base-message path | | Missing output turn | writes both-or-nothing | ✗ silently drops the turn | ✅ every turn persists independently | | Latency guard | ✗ none | ✗ none | ✅ 1.2 s recall budget, fails open to history-only | | Retries | ✗ duplicate extractions | duplicates | ✅ deterministic idempotency seeds | | Dependencies | @mem0/community + SDK params their SDK already removed | deprecated @langchain/classic imports | ✅ zero runtime deps (built-in fetch) |

Install

Self-hosted Flowise (no fork): Flowise scans exactly one directory for nodes — node_modules/flowise-components/dist/nodes (source-verified; there is no custom-nodes env var). Drop the compiled node in:

npm run build   # in this folder → dist/
cp -r dist/nodes/MemorySyncMemory  <flowise>/node_modules/flowise-components/dist/nodes/
cp    dist/credentials/MemorySyncApi.credential.js  <flowise>/node_modules/flowise-components/dist/credentials/
# restart Flowise — "MemorySync Memory" appears under Memory

For Docker, add those two COPY lines to your image or mount them as volumes. Flowise Cloud: requires the node upstream — the PR to FlowiseAI/Flowise is prepared (same file, path-swapped imports) and parked with the other pending submissions.

Usage

1. Add MemorySync Memory (Memory category) to your chatflow
2. Create the MemorySync API credential (key from app.memorysync.io)
3. Set User ID to your end user's id (e.g. from your app's auth — Flowise variables work: {{$vars.userId}})
4. Leave Session ID empty — each Flowise chat automatically gets its own transcript while long-term memory follows the User ID

Memories flow to and from every other MemorySync surface — a fact learned in Flowise is recallable from LangChain agents, Dify, the CLI, voice agents…

Tests

npm install && npm test    # 21 checks, ~5s

The vendored src/flowise.ts interface slice is pinned to Flowise 9291856 (3.1.4); when the real flowise-components package is present it is used instead, and CI diffs the memory contract against Flowise main on every push as a drift alarm.

License

MIT © MemorySync.