--- title: "Why does your computer remember everything but understand nothing?" code: "RP-0108" language: "en" canonical: "https://regentspark.ai/RP-0108/" html: "https://regentspark.ai/RP-0108/" markdown: "https://regentspark.ai/RP-0108.md" updated: "4 April 2026" --- # Research Brief 011 — State & Memory: The Granularity Problem *Everything is a ledger. The question is what language you use to talk about the receipts.* Digital memory spans a vast spectrum — from sub-second undo stacks to permanent blockchain anchors — but every layer was built by a different team with no connection to the layers above or below. CRDTs capture keystroke-level operations with automatic merge. Git captures intentional, annotated commits. Event sourcing and temporal databases make time first-class. Bitcoin provides energy-backed permanence. Between each pair of layers sits a gap: no system lets you smoothly promote a CRDT state to a named version, a file save to a meaningful commit, or a commit to a permanent record. The v1 conclusion — build a unified ledger spanning the full spectrum — was wrong. That's the super-app trap applied to memory. The actual missing piece is a **shared vocabulary for memory intent**: a small set of declarations (ephemeral, working, milestone, record, permanent) that any system can understand and act on. This vocabulary enables promotion and demotion across tiers, gives AI the ability to understand your intent, returns agency to users, and makes existing systems interoperable without replacing them. Forgetting becomes the default behavior of lower tiers — events decay unless explicitly promoted — mirroring how human memory compresses and discards to maintain meaning. **Series:** The Four Primitives **Status:** v2.1 **Date:** April 4, 2026 --- ## What You Already Do > **Summary:** A single paragraph traverses the full memory spectrum — from undo stacks to blockchain notarization — revealing that each layer was built independently with no connection to the others. Your computer remembers everything and understands nothing. This is the granularity problem. You're writing an email. You type a sentence, reconsider, delete half of it, retype. You don't think about this. Your fingers hit keys, the undo stack captures every character, and if you press Ctrl-Z five times you'll get back five steps. This memory lasts seconds. By the time you send the email, every intermediate state — every deleted word, every hesitation — is gone forever. Now zoom out. You finish the email, which is about a project plan. The plan lives in a Google Doc that you and Sarah have been editing for two weeks. The doc has version history — you can scrub back through named snapshots, see who changed what, roughly when. This memory lasts weeks, maybe months. It captures the broad strokes but not the keystrokes. Zoom out further. The project plan becomes a decision. The decision gets recorded in meeting notes. The meeting notes reference a Jira ticket. The ticket links to a git commit. The commit is part of a release. The release is tagged, versioned, deployed. Six months later, someone asks "why did we build it this way?" and the answer is scattered across five systems, none of which know about each other. Zoom out once more. The company's financial transactions are in a ledger. The ledger is audited. Some entries are notarized. A few are anchored to a blockchain. These records are meant to last decades, centuries. They are designed to be undeniable. You just traversed the full memory spectrum of modern computing — from sub-second undo to permanent notarization — in a single paragraph. And you probably noticed: each layer was built by a different team, for a different purpose, with no connection to the layers above or below it. The undo stack doesn't know about version history. Version history doesn't know about git commits. Git doesn't know about the blockchain. Each system picked a granularity and stopped there. This is the granularity problem. Memory in computing isn't missing — it's fragmented across a dozen systems that each handle one slice of the temporal spectrum. The result: your computer remembers everything and understands nothing. --- ## The Spectrum > **Summary:** Every form of digital memory sits on two axes — granularity (how fine-grained?) and permanence (how long kept?). Agency shifts from automatic at the ephemeral end to intentional at the permanent end. No system spans more than two or three adjacent layers, and cost increases with permanence. The unifying pattern is state = f(events) — every layer is an event log differing in what counts as an event, how long it's retained, and what trust model governs it. But recognizing a shared pattern doesn't mean you need a single system. Let's map it. Every form of digital memory can be placed on a plane defined by two dimensions: **granularity** (how fine-grained are the recorded units?) and **permanence** (how long are they kept?). These two dimensions are related but not identical. A CRDT captures fine-grained operations that might persist for the document's lifetime. A file save is coarser — you chose to save — but might vanish when you empty the trash next week. A blockchain entry is the coarsest unit (a hash, a transaction) but the most permanent thing in computing. ```mermaid block-beta columns 4 space:1 A["← Fine-grained"]:2 B["Curated →"]:1 C["Permanent ↑"]:1 CRDT["🔄 CRDT ops\n(fine, long-lived)"]:1 space:1 BTC["⛓️ Bitcoin\n(curated, permanent)"]:1 space:1 AUTO["💾 Autosave"]:1 GIT["📦 Git commit"]:1 LED["📒 Ledger entry"]:1 D["Ephemeral ↓"]:1 UNDO["⏱️ Undo stack\n(fine, seconds)"]:1 FILE["📄 File save"]:1 REL["🏷️ Release tag"]:1 ``` *Two dimensions: vertical = permanence (ephemeral at bottom, permanent at top). Horizontal = granularity (fine-grained left, curated right). Color encodes both: warm/orange = fine-grained operations, cool/blue-purple = curated records.* | Layer | Granularity | Permanence | Example | Who decides? | |-------|-----------|-----------|---------|-------------| | Undo stack | Keystroke | Session (minutes) | Ctrl-Z in any editor | The system, automatically | | CRDT operations | Character/operation | Document lifetime | Automerge, Yjs | The protocol, automatically | | Autosave | Periodic snapshot | Days/weeks | Google Docs, Apple Notes | The system, on a timer | | File save | User-initiated snapshot | Until deleted | Cmd-S | The human, intentionally | | BitTorrent DHT | Content hash + peers | While seeded (hours–years) | Mainline DHT | The swarm, collectively | | Git commit | Curated changeset | Repository lifetime | `git commit -m "..."` | The human, with a message | | Version/release | Tagged milestone | Product lifetime | `v2.1.0` | The team, with ceremony | | Ledger entry | Business event | Regulatory period | Invoice, journal entry | The organization, by policy | | Bitcoin anchor | Hash commitment | Indefinite | OP_RETURN, OP_TIMESTAMP | The network, by energy-backed consensus | Three things jump out. First, **agency shifts as you move toward permanence.** At the ephemeral end, the system remembers automatically — you don't choose to populate the undo stack. At the permanent end, remembering requires deliberate action and real cost. Nobody accidentally anchors something on Bitcoin. The spectrum is a gradient from automatic to intentional. Second, **no system spans more than two or three adjacent layers.** Google Docs covers autosave and crude version history. Git covers commits and releases. A blockchain covers its own entries. Nothing bridges from undo to blockchain. Nothing gives you a unified view of "what happened to this thing, at every scale, since it was created." Third, **cost increases with permanence.** RAM is cheap and fleeting. Disk is cheap and durable. A distributed hash table requires peers to stay online. A blockchain requires energy — real, physical, ongoing energy — to guarantee that records are irreversible. This isn't a flaw. It's the fundamental physics of memory: permanence has a price. ### The unifying pattern Is there one? "Everything is a ledger in a sense" — Nico's observation — points at it. At every layer, the same pattern repeats: 1. **Something happens** (a keystroke, an edit, a commit, a transaction) 2. **It gets recorded** (in a buffer, a log, a DAG, a chain) 3. **State is derived from the record** (the current document, the latest version, the account balance) State = f(events). This isn't a new observation — it's the foundational insight of event sourcing, of Rich Hickey's Datomic, of the entire append-only movement. Every layer of the spectrum is an event log. What differs is: - **What counts as an event** (keystroke vs. commit vs. transaction) - **How long events are retained** (session vs. forever) - **Who decides what to record** (system vs. human vs. consensus) - **What trust model governs the log** (local vs. replicated vs. Byzantine-tolerant) - **What energy backs the permanence** (electrons in RAM vs. proof-of-work) The pattern is universal. But — and this is where v1 of this brief went wrong — recognizing a shared pattern doesn't mean you need a single system. You don't build one pipe that carries drinking water, sewage, and natural gas just because they're all "fluids in tubes." Different permanence layers have different physics, different costs, different trust models. They need different systems. What's missing isn't a unified ledger. It's a shared **language** for talking about memory across these layers. ```mermaid flowchart LR E(["Something\nhappens"]) --> R[("It gets\nrecorded")] --> S["State is\nderived"] ``` *The universal pattern: state = f(events). Every memory layer follows this — what differs is the event granularity, retention period, and trust model.* Nobody has built that language. Let's look at who's built the layers. --- ## CRDTs and Shared State > **Summary:** CRDTs collapse two layers of the spectrum into one — capturing keystroke-level detail AND providing document-level persistence. A CRDT document IS its complete edit history. But this strength creates problems: unbounded growth (tombstones can never be removed without coordination), no semantic boundaries (no built-in concept of a commit or milestone), and no path upward from operation log to meaningful version history. CRDTs solved the bottom of the spectrum with extraordinary elegance but don't connect to the layers above. ### The local-first revolution In 2019, Ink & Switch published an essay that quietly changed how a generation of developers thinks about software. "Local-first software: You own your data, in spite of the cloud" laid out seven ideals for software that works locally, syncs when possible, and never holds your data hostage to a server. Kleppmann, M., Wiggins, A., van Hardenberg, P., & Gentle, M. (2019). Local-first software: You own your data, in spite of the cloud. Onward! 2019. The seven ideals: fast, multi-device, works offline, collaboration, longevity, security/privacy, user ownership. At the heart of their proposal: **Conflict-free Replicated Data Types** (CRDTs). Instead of sending your edits to a central server that arbitrates conflicts, each device maintains its own copy of the data. Edits are operations that can be applied in any order and are guaranteed to converge to the same result. No server needed. No conflict resolution UI. No "someone else is editing this section." The three major CRDT implementations for text: **Automerge** — Martin Kleppmann's research project, now at the Technical University of Munich. Models documents as a tree of nested objects and arrays, with each element tracked by a unique operation ID. Stores the full operation history, so any past state is recoverable. The latest version uses a columnar encoding that reduced document sizes by 50–90x. Kleppmann, M. & Gentle, S. (2020). Automerge: Real-Time Collaborative Text Editing with CRDTs. Kleppmann's broader work: Designing Data-Intensive Applications (O'Reilly, 2017). **Yjs** — Kevin Jahns's JavaScript implementation, probably the most widely deployed CRDT library in production. Used by Notion, JupyterLab, and numerous collaborative editors. Optimized for real-world editing patterns — pragmatic over theoretically elegant. **Diamond Types** — Seph Gentle's Rust implementation, roughly 5,000x faster than earlier CRDT implementations at merging concurrent edits. His "CRDTs go brrr" blog post demonstrated that the performance costs long attributed to CRDTs were implementation issues, not fundamental limitations. Gentle, S. (2021). CRDTs go brrr. Diamond Types demonstrated that careful data structure choices (run-length encoding, efficient skip lists) could eliminate most CRDT overhead. Source: github.com/josephg/diamond-types. ### What CRDTs are, in memory terms A CRDT is an event log with automatic merge. Every edit is an operation. The document at any point is the state derived from applying all operations. This IS the "state = f(events)" pattern — operating at the keystroke level. What makes CRDTs special is that they collapse two layers of the granularity spectrum into one. The operation log captures keystroke-level detail AND provides document-level persistence. A CRDT document IS its complete edit history. Open a year-old Automerge document and you can replay every keystroke, every collaboration session, in order. This means a CRDT document doesn't just store what the thing IS — it stores how the thing BECAME what it is. The process, not just the product. ### What CRDTs don't solve But this strength creates problems that map directly to the granularity issue. **Unbounded growth.** Every operation ever applied is stored forever. Delete a character and the deletion is recorded as a tombstone — a marker that says "this element was here and is now gone." The tombstone can never be removed, because a peer who hasn't seen the deletion yet might try to insert next to the deleted element. A single-page document with ten years of collaborative editing history might weigh megabytes. CRDT tombstone problem: see IPFS discussion on CRDT garbage collection and Yorkie's garbage collection design. Core tension: tombstones are needed for correctness during concurrent editing, but unnecessary once all peers have synchronized. **Garbage collection is hard.** You can prune tombstones IF you know that all peers have seen the deletion. But "knowing that all peers have seen something" requires coordination — exactly the thing CRDTs were designed to avoid. Forgetting requires agreement, but the whole point was to avoid requiring agreement. **No semantic boundaries.** CRDTs record EVERYTHING. Every keystroke. Every cursor movement. But they don't distinguish between "I'm exploring an idea" and "I've decided this is the final version." There's no built-in concept of a commit, a version, a milestone. The granularity is fixed at the finest level. You can't tell the CRDT "remember this moment as important." This last point is the crux. CRDTs solved the bottom of the spectrum — real-time, keystroke-level shared memory — with extraordinary elegance. But they don't connect upward. There's no path from "CRDT operation log" to "meaningful version history." The gap between the operation log and a git commit remains unbridged. --- ## Version Control as Memory > **Summary:** Git accidentally implements something close to human memory: commits are intentional recall (episodic memory), branches are parallel timelines, merges are reconciliation, tags are landmarks. But git is shackled to text — its DAG-of-snapshots model works for anything, but the diff/merge machinery doesn't. The critical gap: no bridge exists between CRDT operation logs and git-style commits. Promoting a CRDT moment to a named version should be seamless, and promoting versions further to releases or records should be equally smooth. This upward promotion chain is what no existing system supports. ### Git's inadvertent model of human memory Git is not a version control system. Well, it is, but that description undersells what Linus Torvalds actually built. Git is a **content-addressable, append-only, DAG-structured history machine.** And it accidentally implements something remarkably close to how human memory works. Torvalds, L. (2005). Git source code management. Git Internals: Git Objects: "Git is a content-addressable filesystem. At the core of Git is a simple key-value data store." Git stores four types of objects (blobs, trees, commits, tags), each identified by the SHA hash of its content. A commit points to a tree (the project state at that moment) plus its parent commit(s). This creates a **directed acyclic graph** (DAG) of snapshots, where each snapshot is a complete picture at one moment. Consider how this maps to human memory: **A commit is an act of intentional recall.** You don't commit every keystroke — you commit when something meaningful happened. "Fixed the login bug." "Restructured the essay." Each commit is a moment you *chose* to remember, accompanied by a message explaining *why*. This is episodic memory: encoding moments that are novel, emotional, or significant — and attaching narrative meaning. **Branches are parallel timelines.** "What if we tried a completely different approach?" Human memory does something similar — we maintain counterfactual narratives alongside actual ones. **Merging is reconciliation.** When two branches come together, git reconciles the differences. Sometimes cleanly, sometimes with conflicts that require human judgment. This mirrors what happens when two people's memories of the same event differ. **Tags are landmarks.** "v2.0" — a moment designated as particularly significant. Not every commit gets a tag. Only milestones. Human memory works the same way: birthdays, graduations, first days. Most days blur together; tagged days persist. ### Why git only works for text Despite this structural elegance, git is shackled to text. Try versioning a Figma file. You can store it — git will track any binary blob — but you can't diff it, merge it, or see meaningful change history. Two versions of a Figma file are opaque to git. This isn't a limitation of git's data model — the DAG of snapshots works for anything. It's a limitation of the **diff and merge machinery**, which operates on lines of text. The concept (snapshots linked by intentional commits with messages) is universal. The implementation is not. This matters because most things people create aren't text files. They're designs, spreadsheets, presentations, databases, canvases, audio recordings. The git model — intentional, annotated, DAG-structured memory — is exactly right. It just needs to work for everything. Brief 008 introduced this idea independently: "versions are entities linked by `derivedFrom`." That's git's commit graph, expressed in entity-relationship terms. Version history is not metadata tucked inside a storage layer — it's a structural relationship between entities. ### The gap between CRDT and git Here's the gap nobody has closed. CRDTs give you automatic, operation-level memory at the bottom. Git gives you intentional, commit-level memory in the middle. But there's no bridge. Imagine: you're writing in a CRDT-powered editor. Every keystroke is captured. Now you pause, review your work, and think: "This is a good stopping point." You should be able to promote this moment in the CRDT operation log to a named version — a "commit" in git terms — without leaving your editor, without switching tools. And later, you should be able to promote that version further — to a released artifact, a published document, a tagged milestone. Each promotion moves the memory up the permanence axis, adding intentionality and metadata while potentially discarding lower-level detail. This upward promotion — from keystroke to version to release to record — is what no existing system supports smoothly. You have to manually export, save, commit, tag, notarize. Each transition is a manual ceremony performed in a different tool. --- ## Append-Only Logs and Event Sourcing > **Summary:** Jay Kreps's insight — the append-only log is the most fundamental data structure in computing — was implemented in Kafka and formalized in event sourcing. Rich Hickey's Datomic went further, making time first-class and treating databases as accumulations of immutable facts. Nostr applies the event-first model to social protocols: everything is a signed, timestamped event; state is always derived. These systems handle the middle of the spectrum but don't bridge upward to permanent records or downward to keystroke-level CRDTs. ### The log is the database In 2013, Jay Kreps — then at LinkedIn, later the co-creator of Apache Kafka — wrote "The Log: What every software engineer should know about real-time data's unifying abstraction." The thesis: **the log — an ordered, append-only sequence of records — is the most fundamental data structure in computing.** Kreps, J. (2013). The Log. Also: Kreps, J. et al. (2011). Kafka: a Distributed Messaging System for Log Processing. Kafka implements this. At its core, Kafka is a distributed commit log — an append-only sequence of events partitioned across machines. The log is the source of truth. Everything else — databases, caches, search indexes — is a materialized view derived from the log. Event sourcing formalizes this. Instead of storing "the current state of an order is: shipped, paid, 3 items," you store the events: OrderCreated, PaymentReceived, ItemsPicked, OrderShipped. The current state is derived by replaying events. Want the state at step 2? Replay events 1–2. Want complete audit history? It's the event log itself. Microsoft Azure Architecture Center: Event Sourcing Pattern. Also: Fowler, M. (2005). Event Sourcing. ### Temporal databases: making time first-class Rich Hickey took this further with Datomic. Traditional databases are fundamentally wrong about time: they model "the world as it is right now" by overwriting old values with new ones. But information is immutable. "The price was $10 on March 1" is a fact that remains true even after the price changes to $12. A database that overwrites $10 with $12 has destroyed information. Hickey, R. (2012). The Datomic Information Model. "Datomic considers a database to be an information system, where information is a set of facts, and facts are things that have happened." Also: Hickey, R. (2012). The Value of Values (talk, JaxConf). Datomic stores **datoms** — atomic facts of the form `[entity, attribute, value, transaction, added?]`. Every fact includes when it became true. The database is an accumulation of facts over time. You can query "as of" any past transaction. Bitemporal databases extend this with two time axes: **valid time** (when was this fact true in the real world?) and **transaction time** (when did we learn about it?). Both timestamps matter for audit, compliance, and understanding how information flowed through a system. SQL:2011 added temporal table support to the SQL standard. XTDB (formerly Crux) implements full bitemporality. ### Nostr: events as the social primitive Nostr takes the event-first model to a social protocol. Every piece of data in Nostr is a **signed event**: a JSON object with an id (SHA-256 hash), a public key, a timestamp, a kind, tags, and content. Events are published to relays. Clients query relays for events matching filters. Nostr protocol: NIP-01 defines the basic event structure. Event kinds define meaning: kind 1 = short text note, kind 0 = profile metadata, kind 3 = follow list. Everything is an event. State is always derived from events by clients. What's interesting for memory: Nostr is event-sourced by nature. Your profile isn't a record — it's the latest kind-0 event signed by your key. Your follow list isn't a table — it's the latest kind-3 event. State is always derived from events. And because events are signed and timestamped, they form a verifiable chronological record. The Nostr model — events, signed, timestamped, relayed — is close to "everything is a ledger." Each user's event stream IS a personal ledger. The question is how long the relays keep the events, and which events supersede which. Nostr itself doesn't guarantee permanence — relays can drop events at any time. For that, you need something heavier. --- ## Bitcoin and the Permanence Anchor > **Summary:** Bitcoin is the most permanent digital record humanity has produced — a continuous append-only ledger running without interruption since 2009, backed by thermodynamics rather than contractual promises. The same ledger transmits value AND records memory. OP_RETURN and OpenTimestamps allow anchoring external data to Bitcoin's permanence. But not everything deserves blockchain permanence — the key architectural insight is tiered permanence: different layers (RAM, disk, peers, blockchain) for different needs, connected by anchoring. Cost signals intended permanence, just as the physical world distinguishes napkin scribbles from stone carvings. ### The ledger that doesn't forget Most of the memory systems we've discussed have a shelf life. Undo stacks last a session. CRDTs last as long as their application runs. Git repos last as long as someone hosts them. Even cloud databases can be decommissioned, acquired, sunset. Bitcoin is different. It is a continuous, append-only ledger that has been running without interruption for over fifteen years. It has no human time — no weekends, no holidays, no downtime — but it has **block time**: roughly one new block every ten minutes, a heartbeat maintained by the collective energy expenditure of the network. Nakamoto, S. (2008). Bitcoin: A Peer-to-Peer Electronic Cash System. As of 2026, Bitcoin has produced 800,000+ blocks without a single break in the chain since January 3, 2009. The longest continuous ledger in digital history. Its properties as a memory system: - **Append-only.** You can add to it. You cannot edit or delete. - **Immutable.** Once a transaction is confirmed (buried under subsequent blocks), reversing it would require more energy than was used to create those blocks — a cost that grows with every passing block. - **Shared by humanity.** Not owned by a company, a country, or a consortium. Anyone can read it. Anyone can write to it (for a fee). - **Energy-backed permanence.** This is the key property. Bitcoin's immutability isn't guaranteed by a legal contract or a company's promise to keep servers running. It's guaranteed by thermodynamics. The energy has already been spent. The record is as permanent as the physical work that produced it. ### Value AND memory on the same ledger Here's what makes Bitcoin uniquely interesting for this research: **the same ledger that transmits value also records memory.** When you send bitcoin, the transaction records a transfer of value. But the transaction is also a timestamped, cryptographically signed event — a memory. "This key sent this amount to that key at this block height." Value and Memory intersect on the same infrastructure. This isn't incidental. Satoshi Nakamoto's core innovation was solving the double-spend problem without a central authority — and the solution was a **shared, ordered memory** of all transactions. The consensus mechanism (proof-of-work) exists to agree on what happened and in what order. Bitcoin is, at its core, a timestamp server backed by energy. Nakamoto (2008): "We propose a solution to the double-spending problem using a peer-to-peer distributed timestamp server to generate computational proof of the chronological order of transactions." The timestamp server IS the innovation — value transfer is the first application built on it. **OP_RETURN** allows embedding arbitrary data (up to 80 bytes) in a Bitcoin transaction. This has been used to anchor external data to Bitcoin's permanence: hash a document, embed the hash in an OP_RETURN output, and you have a timestamped proof that the document existed in its current form at the time of that block. The document itself lives elsewhere — on your machine, in a database, on IPFS — but its existence is anchored to the most permanent digital record humanity has produced. **OpenTimestamps** formalizes this pattern: given any file, produce a proof that the file existed at a certain point in Bitcoin's timeline. The proof is tiny (a few hundred bytes), the file itself never touches the chain, and the anchor is as permanent as Bitcoin itself. OpenTimestamps: "A timestamping proof standard. Uses Bitcoin as a timestamp notary." Created by Peter Todd. Also: OP_RETURN — allowed since Bitcoin Core 0.9 (2014) for data embedding. ### Tiered permanence Not everything deserves blockchain permanence. This is an essential insight that v1 of this brief missed. Your undo stack doesn't need to be on Bitcoin. Your CRDT operations don't need proof-of-work. Most drafts, most messages, most daily work is appropriately ephemeral. Storing everything permanently would be wasteful — not just of storage, but of energy. Immutability has a cost, and that cost is a feature: it forces you to choose what's worth remembering forever. The physical world has always worked this way. Scribbling on a napkin costs nothing and the napkin gets thrown away. Printing a book costs more and lasts decades. Carving in stone costs a lot and lasts centuries. The cost of the medium signals the intended permanence of the message. A society that carved every napkin scribble in stone would grind to a halt. ```mermaid graph LR RAM(["⏱️ RAM\nfree · seconds"]) DISK[("💾 Disk\ncheap · days–years")] PEERS{{"🌐 Peers\nmoderate · months"}} CHAIN[/"⛓️ Blockchain\nenergy-backed · permanent"/] RAM -->|"auto-decay"| DISK DISK -->|"replicate"| PEERS PEERS -->|"anchor hash"| CHAIN ``` Compare Bitcoin's permanence with **BitTorrent's DHT** (Distributed Hash Table). BitTorrent's Mainline DHT is a distributed system too — millions of nodes storing content-addressed data. But it has no proof-of-work, no energy-backed immutability. Data persists as long as peers hold it and respond to queries. Stop seeding, and eventually the content becomes unreachable. This makes the DHT excellent for social data that should be broadly available but doesn't need to last forever: profile metadata, social graphs, ephemeral content. It's the middle tier — more permanent than a single server, less permanent than a blockchain. BitTorrent Mainline DHT: based on Kademlia. As of 2026, one of the largest distributed systems in operation with millions of active nodes. Used by projects like BEP 44 for mutable/immutable data storage beyond file sharing. Nostr operates in a similar permanence tier. Relays store events, but relays can drop events, go offline, or shut down. Your Nostr event stream is more durable than a single server (because multiple relays may store it) but less durable than a blockchain (because no relay is obligated to store it forever). For truly permanent records, Nostr events can be *anchored* to Bitcoin — the relay-layer data stays on relays, but a hash of the event (or a batch of events) gets timestamped on-chain. This layering is the key architectural insight: **different permanence tiers for different needs, connected by anchoring.** The CRDT captures every keystroke in RAM and on disk. The meaningful versions get committed and replicated to peers. The truly important milestones get anchored to the blockchain. Each layer uses the right technology for its permanence requirements and cost tolerance. The layers don't need to be one system. They need to be able to reference each other. --- ## The Forgetting Problem > **Summary:** Human memory forgets by design — decay, importance-weighted retention, compression, and reconstruction are features, not bugs. Digital systems do the opposite: remember everything, understand nothing. GDPR's right to erasure collides directly with append-only architectures. The middle ground — graceful, importance-weighted, progressive forgetting — remains unbuilt. The tiered permanence model provides a mechanism: events naturally decay down the tiers unless promoted. Forgetting isn't a separate system — it's the default behavior of the lower tiers. ### Digital memory's pathological totality Human memory forgets. This is not a bug. Neuroscience has shown it's an essential feature. Frederic Bartlett's work in the 1930s established that human memory is **reconstructive**, not reproductive. We don't play back recordings — we reconstruct memories from fragments, filling gaps with schemas. Each act of remembering is an act of creation. Memories change every time we recall them. Bartlett, F. C. (1932). Remembering: A Study in Experimental and Social Psychology. Also: Schacter, D. L. (2001). The Seven Sins of Memory (Houghton Mifflin) — catalogues forgetting, distortion, and interference as functional features. This seems like a flaw. But consider the alternative. A rare condition called hyperthymesia gives some people near-perfect recall of daily life. Studies reveal something surprising: total recall doesn't improve decision-making, and it can impair it. Being unable to forget means being unable to generalize. The forest is invisible because you see every individual leaf. Forgetting serves at least three functions: 1. **Compression.** You don't remember every meal you've ever eaten. You remember "I like sushi" and "that restaurant was bad." Generalizations extracted from thousands of forgotten specifics. 2. **Relevance filtering.** The memories that persist are the ones that matter — emotional, novel, repeated, or connected to existing knowledge. Everything else fades. A natural retention policy. 3. **Narrative coherence.** We edit our memories to form coherent stories. The messiness of actual experience gets smoothed into "what happened." This isn't dishonesty — it's how we make sense of the world. Digital systems do the opposite. They remember everything and understand nothing. Your email inbox contains every message since 2008. Your Google Drive has files from projects you've forgotten existed. Your phone has 47,000 photos. The data is all there. The meaning is gone. Perfect memory without selective forgetting produces the digital equivalent of hoarding. ### GDPR and the right to forget The EU's GDPR enshrines a "right to erasure" (Article 17): individuals can demand that organizations delete their personal data. This creates a direct collision with append-only architectures. GDPR Article 17: Right to erasure ('right to be forgotten'). For the blockchain tension: Oxford Academic (2025), Reconciling blockchain technology and data protection laws. If your system is an append-only event log, how do you delete something? The event that recorded "Alice bought a book at 3 PM" is an immutable fact. Deleting it would break the log. Current approaches: - **Off-chain storage:** Store personal data off-chain; put only a hash on-chain. Delete the off-chain data on request. The hash becomes meaningless without its source. - **Crypto-shredding:** Encrypt data before writing to the log. On deletion request, destroy the encryption key. The encrypted data remains but is unreadable. - **Redaction events:** Append a new event marking the old event as redacted. Not true deletion, but functional erasure. None are fully satisfying. They're patches over a fundamental tension: append-only systems assume you never need to forget. The real world requires forgetting. ### Should digital memory be more like human memory? The question isn't whether digital systems should forget — they must, for practical (storage), legal (GDPR), and cognitive (usability) reasons. The question is: what model of forgetting? Human memory offers a provocative template: - **Decay by default.** Unless reinforced, memories fade. Digital equivalent: events expire after a retention period unless explicitly promoted. - **Importance-weighted retention.** Emotional or novel events are remembered better. Digital equivalent: events that triggered decisions or were explicitly marked are retained longer. - **Compression over time.** Detailed memories of last week become vague memories of last month. Digital equivalent: fine-grained events are periodically compressed into summaries. - **Reconstruction from fragments.** Human memory fills gaps with plausible inferences. Digital equivalent: maintain enough summary data to reconstruct approximate past states without bit-perfect replay. No existing system works this way. Current systems offer a binary: remember everything forever or delete irrevocably. The middle ground — graceful, importance-weighted, progressive forgetting — remains unbuilt. ```mermaid flowchart TB subgraph human["Human Memory Model"] direction TB DECAY["⏳ Decay by default\nunless reinforced"] WEIGHT{{"⚖️ Importance-weighted\nretention"}} COMPRESS["📦 Compression\nover time"] RECON(["🧩 Reconstruction\nfrom fragments"]) DECAY --> WEIGHT --> COMPRESS --> RECON end subgraph digital["Digital Equivalent"] direction TB EXPIRE["Events expire unless\npromoted"] MARKED{{"Triggered / marked\nevents retained longer"}} SUMMARY["Fine events compressed\nto summaries"] APPROX(["Approximate past states\nwithout bit-perfect replay"]) EXPIRE --> MARKED --> SUMMARY --> APPROX end ``` *Human forgetting as a design template for digital memory. Each human mechanism has a digital equivalent that no existing system fully implements.* The tiered permanence model from the Bitcoin section gives us a mechanism for this: **events naturally decay down the tiers unless promoted.** The CRDT operation log compacts after the document is committed. The committed version gets pruned to a summary after the release. Only what's explicitly anchored persists permanently. Forgetting isn't a separate system — it's the default behavior of the lower tiers. --- ## Memory Across Spaces > **Summary:** When objects cross Space boundaries, their memory faces three options: full history transfer (overwhelming, privacy-violating), snapshot transfer (amnesia — the Downloads folder problem), or selective history (curated, like a git push). The physical world provides the template: a ceramic bowl carries who made it and what it is, but not every failed attempt or the maker's frustrations. Social defaults determine what carries automatically (creator, approximate time, current state), what requires explicit choice (provenance, process notes), and what never crosses unless volunteered (private drafts, deleted content). ### When objects move, what happens to their history? Brief 010 established that Spaces are namespaces — isolated, scoped environments where you bring things in and work with them. The closed-door axiom says: when you're in a Space, the outside doesn't exist. Now consider: when an object crosses a Space boundary, what happens to its memory? Take a concrete example. You write a research brief in your private workspace (Space A). You edit it over three weeks, accumulating CRDT history, commit messages, reviewer comments. Then you move it to a shared project Space (Space B) for collaboration. Several things could happen: **Full history transfer.** The brief arrives with its complete history — every keystroke, every comment, every version. Maximally transparent but potentially overwhelming and privacy-violating. Maybe you don't want collaborators seeing your 3 AM editing sessions. **Snapshot transfer (amnesia).** The brief arrives as it is now, with no history. Clean slate. This is what happens when you email someone a file — it arrives stripped of all context. The Downloads folder problem from Brief 008. **Selective history.** The brief arrives with curated history — named versions, commit messages, reviewer comments marked as "public." The messy intermediate states are pruned. This is what a git push does: you share your commits but not your stash, your working directory, your abandoned branches. ### The physical world gets this right This is where computing can learn from how rooms already work. You spend a week making a ceramic bowl at home. You knead the clay, shape it, fire it, glaze it, fire it again. Then you bring it to a friend's dinner party. What carries with the bowl: - **Who made it.** "I made this." That's automatic — social default. - **Roughly when.** "I made it last week." Approximate time, not a timestamp. - **What it is.** Obviously — it's a bowl. Its current state is self-evident. What doesn't carry: - **Every failed attempt.** You didn't bring the three bowls that cracked in the kiln. - **The full process.** Your friend doesn't see the kneading, the centering, the hours at the wheel. - **Your private frustrations.** "I almost threw the clay across the room at 2 AM" stays in your kitchen. Some things are your choice to share: - "The glaze is an experiment — first time with this color." - "The shape is inspired by a bowl I saw in Japan." - These are provenance details you volunteer, not ones that travel automatically. This maps precisely to Brief 010's closed-door axiom. The friend's dinner table is a Space. The bowl enters it. The friend sees the bowl as it is now, knows who made it (social default), and learns what you choose to tell them. Your private workshop — your Space A — remains invisible. Not "access denied" — the workshop doesn't exist from the dinner table's perspective. Brief 010: "When you're in a Space, the outside doesn't exist. Not hidden. Not locked. Not filtered. Nonexistent." The closed-door axiom applied to memory means: the private history of how something was made is not "hidden from view" in the new Space — it literally isn't part of the new Space's universe. The rules for what carries across Space boundaries should follow the same social logic: - **Automatic (social defaults):** Creator identity, approximate creation time, current state. These carry because it would be weird if they didn't — like a bowl with no maker. - **Explicit choice:** Detailed provenance, version history, process notes. The creator chooses what to share. - **Never (unless you say so):** Private drafts, deleted content, intermediate states. Your 3 AM editing session is the clay that cracked in the kiln. ```mermaid graph LR subgraph SA["🔒 Space A — Private workshop"] D1["v0.1\n(rough draft)"] D2["v0.2\n(restructured)"] D3["v0.3\n(polished)"] D1 --> D2 --> D3 end subgraph SB["🌐 Space B — Shared project"] D4["v1.0\n(shared for review)"] D5["v1.1\n(with feedback)"] D4 --> D5 end D3 -.->|"carries:\n👤 author\n📅 ~when\n📄 current state\n\ndoesn't carry:\n🚫 v0.1, v0.2\n🚫 private edits"| D4 ``` ### The provenance chain Provenance — the record of where something came from and how it was transformed — is a specific kind of memory that becomes critical when objects move between Spaces. The provenance link between Space A and Space B is the critical memory artifact. Without it, Space B doesn't know the brief went through private drafts. With it, you can trace backward — but only if Space A's owner permits it. Privacy and provenance are in tension. The physical-world model resolves this: the bowl's maker can tell you about the process if they choose, but you can't walk into their kitchen uninvited. Brief 008's entity model provides the vocabulary: each version is an entity linked by `derivedFrom`. The question is which version-entities are visible in which Space, and whether the `derivedFrom` chain crosses Space boundaries. The answer is: it crosses, but only one hop — you can see "this was derived from something in a private Space" without seeing the private Space's contents. --- ## Objects as Memory Atoms? > **Summary:** Memory events (CRDT operations, git commits, ledger entries) all fit Brief 008's entity model — they have identity, properties, and relationships. This suggests memory events ARE objects, unifying the ontology. But there's a counter-argument: memory might be fundamentally relational — not an object but a connection between objects and time. Both views have merit, and the entity ontology is flexible enough for both. Regardless of ontological status, memory events need the same two properties: a position on the granularity axis and a position on the permanence axis. ### An open question Brief 008 defined an entity as anything with identity, properties, and relationships — and gave entities four optional capabilities: +content, +containment, +agency, +narrative. Memory (+narrative) was one of these capabilities. But now that we've mapped the granularity spectrum, a harder question emerges: **Are memory events themselves objects?** Consider what the granularity spectrum actually contains: - A CRDT operation batch is... a thing. It has an identity (the operation IDs), properties (timestamp, author), and relationships (part of this document's history). - A git commit is... a thing. It has an identity (the SHA), properties (message, author, date), and relationships (parent commits, the tree it points to). - A release tag is... a thing. - A ledger entry is... a thing. - A Bitcoin transaction is... a thing. Each of these fits the entity model from Brief 008. Each has identity, properties, and relationships. Each could carry capabilities — a commit has +content (the diff), a release has +containment (the artifacts it bundles). If memory events are objects-with-context, then the granularity spectrum isn't a separate concern from the entity ontology — it's the entity ontology applied to temporal artifacts. A CRDT operation is an entity with high granularity and low permanence. A blockchain anchor is an entity with low granularity and high permanence. The "memory layer" is just the set of entities that happen to be *about* change over time. ### The other side But there's an argument against this unification. Memory might be a fundamentally different *kind* of thing — not an object, but a relationship between objects and time. When you remember making the ceramic bowl, the memory isn't a thing you can hold. It's a connection between you (a person), the bowl (an object), your kitchen (a space), and last Tuesday (a time). The memory is *about* those things but isn't one of them. Memories are relational, not substantial. In technical terms: a CRDT operation isn't the same kind of entity as the document it modifies. The operation is metadata *about* the document's evolution. It exists in a different conceptual plane — the plane of "what happened" rather than "what is." Both views have merit: | Memory-as-object | Memory-as-relationship | |:---:|:---:| | Simplifies the ontology (one model for everything) | Preserves a meaningful distinction | | Memory events can be versioned, shared, moved between Spaces | Memory is always *about* something — it's second-order | | A commit is clearly a thing (it has a SHA, you can `git show` it) | But the commit only makes sense in relation to its parent and its content | | Enables "memory about memory" (meta-memory is just another entity) | Avoids infinite regress — memory is the narrative layer, not another object layer | We don't resolve this here. It may be that the answer is contextual: some memory events (a commit, a ledger entry) are object-like enough to be treated as entities. Others (the fact that you edited this document at 3 AM) are better modeled as properties of a relationship. The entity ontology is flexible enough for both — relationships are entities too, per Brief 008. What we *can* say: whether memory events are objects or relationships-about-objects, they need the same two properties we've been discussing. They need a position on the **granularity** axis (how detailed?) and a position on the **permanence** axis (how long kept?). The vocabulary for describing memory intent applies regardless of ontological status. --- ## The Language of Memory Intent > **Summary:** Four gaps define the landscape: CRDT operations → meaningful versions, file save → git commit, git commit → permanent record, and cross-system provenance. The v1 conclusion (build a unified ledger) was the super-app trap. The real primitive isn't a system — it's a vocabulary of memory intent: ephemeral, working, milestone, record, permanent. These declarations let any system understand and act on your intent, enable AI to reason about your data, return agency to users, and make existing systems interoperable through a shared bridge language. ### What's actually missing We've surveyed the landscape. CRDTs handle the left edge (real-time operations). Git handles the middle (intentional commits). Event sourcing handles business events. Bitcoin handles the right edge (permanent records). BitTorrent DHT and Nostr handle the middle tiers. Between each pair, there's a gap: ```mermaid flowchart LR CRDT(["🔄 CRDT\noperations"]) -.->|"Gap 1"| VER["🏷️ Meaningful\nversions"] SAVE(["💾 File\nsave"]) -.->|"Gap 2"| GIT["📦 Git\ncommit"] GIT -.->|"Gap 3"| RECORD[/"📒 Permanent\nrecord"/] APP1(["App A\nmemory"]) -.->|"Gap 4"| APP2(["App B\nmemory"]) ``` *Four gaps in the memory landscape. Dashed arrows = no smooth path exists today. Each gap requires a manual ceremony in a different tool.* **Gap 1: CRDT operations → meaningful versions.** No system lets you smoothly promote a CRDT state to a named version. **Gap 2: File save → git commit.** The vast majority of computer users never use version control. The gap between Cmd-S and a meaningful commit is both conceptual and practical. **Gap 3: Git commit → permanent record.** If something matters enough to be notarized, you need a different system entirely. **Gap 4: Any system → cross-system provenance.** Even within one granularity level, memory is siloed per application. Google Docs history doesn't know about git commits. Git doesn't know about Jira tickets. Each application maintains its own memory. v1 of this brief concluded: build a unified ledger. One system spanning the full spectrum. One event format, one retention engine, one promotion chain. That's wrong. It's the super app trap applied to memory — the impulse to absorb all adjacent functions into one system. Every app tries to be the everything-app. Nico identified the same pattern at the Spaces level: "Every app is trying to solve this. But these are not universal solutions. The user is left with super apps that are even more complex." Nico on the unified ledger conclusion: "I don't think that's ever going to work. We need a layered architecture and we need a primitive." (April 4, 2026) A unified ledger spanning from undo stacks to blockchain would need to handle temporal dynamic range of roughly 10^15 (sub-millisecond to permanent), the full spectrum of consensus models (local to Byzantine-tolerant), and every conceivable event schema. It would be a Swiss Army knife the size of a building. Nobody would use it. And even if they did, it would become the single point of failure for all memory — exactly the centralization problem that distributed systems exist to avoid. ### The primitive isn't a system. It's a vocabulary. Here's the reframe. The missing piece isn't a system that handles all layers. The missing piece is a **language** — a shared vocabulary for expressing what kind of memory you want. When you say "keep this forever," you're expressing a memory intent. When you say "this is just a draft," you're expressing a different one. When you say "I want to be able to undo this for the next hour but don't care after that," that's another. Right now, these intents have no consistent way to be expressed. Each system has its own mechanism — git has commit messages, Google Docs has auto-version history, Bitcoin has transactions — but there's no shared vocabulary that spans them. What if there were? Consider a small set of memory-intent primitives: - **"This is ephemeral."** Keep it in RAM, local disk at most. Undo-stack permanence. - **"This is a working state."** Keep it for the lifetime of the project. CRDT or autosave permanence. - **"This is a milestone."** Keep it explicitly. Name it. Git-commit permanence. - **"This is a record."** Keep it for compliance, audit, or personal importance. Ledger permanence. - **"This is permanent."** Anchor it. Make it undeniable. Blockchain permanence. These aren't API calls to a unified system. They're **declarations of intent** that any system can understand and act on. A CRDT library that understands "this is a milestone" can create a named snapshot. A git system that understands "this is a record" can tag and sign. A timestamping service that understands "this is permanent" can anchor to Bitcoin. Different systems handle different permanence tiers — but they share the vocabulary. ```mermaid graph LR subgraph intent["What you say"] I1["⏱️ ephemeral"] I2["📝 working"] I3["🏷️ milestone"] I4["📒 record"] I5["⛓️ permanent"] end I1 -.->|"Undo / RAM"| I2 I2 -.->|"CRDT / Autosave"| I3 I3 -.->|"Git / Versions"| I4 I4 -.->|"Ledger"| I5 I5 -.->|"Bitcoin"| OUT((" ")) ``` *The vocabulary is the primitive. The systems underneath are interchangeable.* The vocabulary enables **promotion** — moving memory up the permanence axis by changing the intent declaration. And demotion — deciding that something previously marked as a "record" is actually just a "working state" and can be compressed. ### Why language changes everything Three consequences of having a shared vocabulary for memory intent: **1. AI can understand your intent.** Today, an AI assistant has no way to know whether a document is precious or disposable. With memory-intent vocabulary, you can tell it: "This is a draft" or "This matters — keep it forever." The AI can then act appropriately: suggesting cleanup for drafts, suggesting anchoring for permanent records, warning you before destructive operations on things you've marked as important. **2. You regain agency.** Right now, each application's memory behavior is invisible and non-negotiable. Google Docs auto-saves whether you want it to or not. Git remembers nothing unless you manually commit. There's no way to express "I want this to be remembered at the version level, not the keystroke level." With a vocabulary for intent, you can communicate your expectations — and the system becomes legible. **3. Existing systems become interoperable.** You don't need to replace Google Docs, git, or Bitcoin. You need a bridge between them — a way for one system to hand off to another when the permanence level changes. The vocabulary IS that bridge. "This is now a milestone" is a message any system can listen for and act on. Nico on language as the key: "When we have language that describes the different types of memory, we're mostly there. Because AI can understand your intent. You regain agency because you can communicate expectations using social rules. Existing systems become usable because you have a bridge." (April 4, 2026) This is the same insight that drives Regent's Park's approach to all four primitives: the answer isn't building a new system. It's finding the right vocabulary — simple enough to feel obvious, precise enough to be actionable. People already think about memory in these tiers. "Just a note" vs. "important document" vs. "legal record" — these are natural categories. What's missing is a way to tell your computer which tier you're in. --- **Key findings:** - Memory in computing isn't missing — it's fragmented across a dozen systems that each handle one slice of the temporal spectrum, with no connections between layers - The universal pattern is state = f(events), but different permanence layers have different physics, costs, and trust models — they need different systems, not one unified ledger - CRDTs solved real-time collaborative memory with elegance but provide no path upward to meaningful versions; git solved intentional versioning but only for text - Permanence has a price, and that price is a feature: cost signals intended permanence, just as stone carvings cost more than napkin scribbles - The tiered permanence model (RAM → disk → peers → blockchain) provides a mechanism for graceful forgetting: events decay down the tiers unless explicitly promoted - When objects cross Space boundaries, physical-world social defaults provide the template: creator and current state carry automatically; process history requires explicit sharing - The missing primitive is not a system but a **vocabulary** — a small set of memory-intent declarations (ephemeral, working, milestone, record, permanent) that any system can understand and act on ## Open Questions ### 1. What is the primitive, exactly? We've argued for a vocabulary of memory intent. But is it a metadata standard? A set of annotations? An API? A protocol? The vocabulary needs to be lightweight enough to attach to any event in any system, but structured enough that different systems interpret it consistently. What's the minimal specification? ### 2. Can memory events be objects? Section 6 presented both sides but didn't resolve it. If memory events (commits, CRDT batches, ledger entries) are entities per Brief 008, the ontology stays unified. If memory is a separate relational layer *about* entities, the model is richer but more complex. Can we design the vocabulary to work either way? ### 3. What are the social defaults for cross-Space memory? The ceramic bowl analogy suggests some memory carries automatically (creator, approximate time) and some requires explicit sharing. But what's the actual list of social defaults? And do they vary by culture, context, or relationship type? Brief 010's closed-door axiom gives the mechanism. The social defaults give the policy. ### 4. How does forgetting compose with permanence? If I anchor a document hash to Bitcoin and then want to exercise my right to erasure, the hash is permanent but the document is deleted. Is this sufficient forgetting? The hash proves *something* existed, even if the something is gone. Is that a privacy violation or a reasonable trace? ### 5. Who pays for permanence? Bitcoin anchoring costs money (transaction fees). Storage costs money. If memory intent includes "make this permanent," someone pays. Is permanence a premium service? A utility? Does the cost itself serve as a natural filter — only things worth paying for get remembered permanently? ### 6. What's the minimum viable vocabulary? Five tiers (ephemeral → permanent) might be too many. Or too few. What's the smallest set of memory-intent declarations that covers the vast majority of real use cases? Maybe just three: **draft**, **version**, **record**. Or maybe two: **forgettable** and **permanent**, with everything else implied by context. ### 7. Where does the vocabulary live? In the file? In the filesystem? In the application? In a sidecar metadata store? In the entity's properties (per Brief 008)? The answer probably varies by permanence tier — ephemeral intents live in RAM, permanent intents live on-chain — but the interface should feel unified. --- ## Coda: Memory as Language > **Summary:** Memory isn't one system — it's a layered architecture with different systems handling different permanence tiers. The connective tissue between them isn't a unified platform but a vocabulary: simple declarations of intent that any system can understand. The granularity problem gets solved not by one system to rule them all, but by giving people and their AI the words to describe what they need. Memory was always the most abstract of the four primitives. People are intuitive — you know what a person is. Spaces are intuitive — you know what a room is. Objects are intuitive — you know what a thing is. Memory is harder to point at because it's not a thing — it's the story of things. This research makes its shape clearer. Memory isn't one system. It's a **layered architecture** — CRDTs at the bottom, version control in the middle, distributed ledgers and blockchains at the top — with different systems handling different permanence tiers. The layers exist. They work. What's missing is the connective tissue between them. That connective tissue isn't a unified platform. It's a **vocabulary**: a small, shared language for expressing what kind of memory you want. "This is a draft." "This is a milestone." "This is permanent." Simple declarations that any system can understand and act on. The granularity problem — memory fragmented across disconnected systems — doesn't get solved by building one system to rule them all. It gets solved by giving people (and their AI) the words to describe what they need. Once you can express intent, the right layer can respond. Once layers can hear the same vocabulary, they can hand off to each other. Once handoff works, promotion and forgetting become natural — not manual ceremonies in different tools, but smooth transitions driven by your stated intent. Everything is a ledger. But the answer isn't one ledger. It's a language for choosing which ledger — and for how long. --- *Regent's Park · Brief 011 · v2.1* *Context: 005 — Four Primitives · 005d — Memory · 008 — Entity Ontology · 010 — Spaces as Namespaces* 🌳