Browse / General-purpose / agent-memory
agent-memory
atvirokodosprendimai
archivedARCHIVED 2026-08-26 - superseded by agentsmemory: https://github.com/atvirokodosprendimai/agentsmemory
Open atvirokodosprendimai/agent-memory → Does not match the four rules.
Works with any agent
ships config for opencode, agents.
In its own words
E2E encrypted agent memory on IPFS — portable, decentralized knowledge persistence
Agents (Goose, Copilot, Claude Code, observation loops) generate institutional knowledge — decisions, failures, learnings, context. That knowledge currently dies with the session. agent-memory fixes this by providing encrypted, content-addressed, decentralized persistence that any agent can write to and read from.
Why
- Billing integration has been attempted 3 times. Zero traces of those attempts exist in any memory system.
- Observation loop runs 65 times, sees GitHub state, but cannot see decisions made outside GitHub.
- m4 vault has 523 traces, 485 essences — rich personal memory, but agents can't write to it.
- The pipeline's
collect-memory.shcan only surface what's already been captured.
The gap: work happens in sessions. Sessions end. Knowledge evaporates. Next session starts from zero.
How it works
- Agent writes a memory entry (JSON: type, content, tags, timestamp, source)
- Entry is encrypted with AES-256-GCM using a key derived from the agent's secret (HKDF, same pattern as wgmesh)
- Encrypted blob is pinned to IPFS via a local Kubo node or Helia (browser/runtime)
- CID is the address — content-addressed, immutable, decentralizable
- An index (also encrypted) maps tags/types → CIDs so agents can query by topic
- Any agent with the key can decrypt and read. Without the key, it's opaque ciphertext on IPFS.
Quoting 67% of the README. Read the rest on GitHub ↗
Read from the repository's git tree on 2026-08-17.