# Architecture > For the compact current project map and source-precedence rules, start with [`../CONTEXT.md`](../CONTEXT.md). This guide expands the machine model. Older book/issues/diagrams that draw a separate capability plane are preserved research history rather than the current conceptual ownership. Cursors is easiest to understand as one durable loop: ```text intent ↓ reference / resolve ↓ coordinate / exchange ↓ verify cursor-carried authority ↓ execute on a body ↓ record outputs + receipts ↓ new cursor ``` A **cryptocursor** is the durable part: causal continuation, authority lineage, immutable state/input/output references, and effect evidence. Bodies, transports, sockets, tabs, processes, and machines are replaceable machinery around that loop. > Given immutable parents, named inputs, an authorized continuation, and a suitable execution body, produce a new sealed cryptocursor plus named outputs and receipts. Everything below exists to make that operation inspectable without collapsing unrelated concepts together. ## Start with the separations Before learning individual components, keep these boundaries fixed: | Do not collapse | Why | | --- | --- | | reference ↔ authority | Knowing what/where something is does not grant permission to use it. | | transport ↔ identity | A connected peer is not automatically a known participant. | | body ↔ Self | A machine or browser tab is temporary; identity and lineage may survive it. | | delivery ↔ execution | Receiving a request does not mean it was authorized or performed. | | source ↔ executable authority | Lua, formulas, blocks, IR, and Wasm bytes are data until validation and cursor-carried authority permit execution/effects. | | authority evidence ↔ separate authority universe | Grant/split records can be independently addressed and verified without becoming a top-level graph independent of the cursor continuation they constrain. | If the cockpit ever makes one side visually imply the other, treat that as a design bug. ## Read the cockpit like machinery There are three visible scales: ```text component / node ↓ wire / relationship ↓ message specimen on that wire ``` A node tells you **what machinery you selected**. A wire tells you **which relationship is being inspected**. A message specimen tells you **what semantic material can cross that relationship and what its fields/proof boundary mean**. For example: ```text [ MAILBOX ] ── envelope/v1 ──▶ [ CRYPTOFABRIC ] id subject parents[] author evidence authority refs[] payload receipt policy ``` The carrier beneath that envelope may later be WebRTC, HTTP, local memory, Metasocketry, or something else. The message does not become less meaningful just because the carrier changes. ## The machine, in useful order ### 1. Cryptocursor history and authority: what happened, and what may continue? A cryptocursor is an immutable signed point in causal execution history. It can name parents, continuation/checkpoint references, inputs, outputs, **authority lineage/evidence**, receipts, author, body hint, and logical time. Fan-out creates several children. Fan-in creates a child naming several parents. Advancing never rewrites the old record. Authority follows the same causal discipline: attenuation/delegation/split decisions belong to the advancing continuation and cannot silently become stronger because execution branched or moved. CURSO/0 currently represents authority with cursor `grants[]` plus independently sealed grant/split records. Those records remain real protocol artifacts and independently verifiable evidence. They are **not a separately living top-level capability plane**. [Inspect CURSOR HISTORY](#cursors-inspect:plane:history) Read: [Cursor Records](crypto-cursors.md) and the CURSO/0 compatibility profile. ### 2. Cryptopointers: what are we trying to resolve? A cryptopointer carries a target plus enough context to ask for a useful view: resolver constraints, trust references, curve hints, locality preferences, and related metadata. It is not a raw distributed memory address and not authority merely because somebody knows it. ```text pointer + requested view + constraints ↓ verified resolver plan ↓ mapping | fetch | computation | redirect | denial ``` [Inspect HORIZON CRYPTOPOINTER](#cursors-inspect:pointer:horizon) Read: [Cryptopointers](cryptopointers.md). ### 3. Curves: whose projection of the world? A curve describes the current relative view of a world. Different bodies may legitimately see different projections because cursor-carried authority, locality, trust, invitation scope, and cost differ. A curve may be local to one browser or deliberately shared. It does not replace cryptographic identity or authority lineage. [Inspect LOCAL CURVE](#cursors-inspect:curve:local) Read: [Curve Spaces](curve-spaces.md). ### 4. Mailboxes and exchanges: where does addressed meaning move? Mailboxes accept addressed, deduplicated envelopes. Exchanges move meaningful material such as requests, replies, pointers, cursor references, assertions, authority evidence, and receipts. Transport arrival alone proves no authorship or authority. Signed envelope/cursor material can carry stronger evidence when independently verified. [Inspect LOCAL MAILBOX](#cursors-inspect:mailbox:local) Read: [Mailboxes and Traffic](mailboxes.md). ### 5. Cryptofabric programs: what work is proposed? Cursors programs should be inspectable before they execute. The first combinators form a deliberately small plan language: ```text exchange(target) mailbox(address) exec(program) split(...branches) sequence(...steps) ``` These are plan nodes, not ambient permission. A program can describe where cursor-carried authority will be required and which steps may cause external effects before a body runs anything. This layer can grow operators such as `resolve`, `join`, `race`, `retry`, `assert`, `interest`, `store`, `checkpoint`, `delegate`, and `observe` without changing the lower transport model. Read: [Cursor Apps and Contemporary Runtimes](cursor-apps.md). ### 6. Cryptofabrics: how can material move or persist? A cryptofabric is carrier/store/recovery machinery. Higher-level envelope semantics survive changes in carrier. A browser body can reason about local/browser mechanisms such as MessagePort, BroadcastChannel, browser storage, WebRTC/WebTorrent, HTTPS webseeds, and eventually Metasocketry handles. Other bodies may add TCP, µTP, DHT, iroh/libp2p, removable media, radio, or delay-tolerant stores. The carrier still proves only carrier facts. A cryptofabric plan does not manufacture cursor identity or authority. [Inspect BROWSER CRYPTOFABRIC](#cursors-inspect:fabric:browser) [Inspect LOCAL CRYPTOFABRIC](#cursors-inspect:fabric:local) Read: [Cryptofabrics](cryptofabrics.md) and [Fallback Fabric](fallback-fabric.md). ### 7. Cursor authority: who may cause what? Authority is part of the cryptocursor continuation, not a fifth independent semantic plane. A cursor may cite independently sealed authority evidence describing resources, rights, budgets, validity, delegation/attenuation constraints, split allocations, and presentation/redemption conditions. Verification evaluates that evidence as part of deciding whether this continuation may advance or cause an effect. ```text parent cursor authority ↓ attenuate / delegate / partition child cursor authority ↓ present at operation boundary independent verifier ↓ allow | deny | unknown ``` Parallelism must not duplicate consumable authority. Migration must not increase authority. Joining branches requires an explicit authority rule rather than assuming unions are safe. A signature authenticates the signer; it does not by itself establish that the requested operation is authorized. The historical [Capabilities](capabilities.md) guide remains useful for CURSO/0 grant mechanics and attenuation rules, but interpret those records as materialization of cursor authority lineage rather than a separate top-level runtime graph. ### 8. Body / exec: where does computation happen now? A body is a replaceable execution site: browser, process, worker, VM, machine, mobile app, embedded device, or another compatible executor. A body resolves inputs, verifies the relevant history and cursor-carried authority, restores the continuation, executes within explicit constraints, persists outputs, and returns receipts/evidence. [Inspect SELF / BODY](#cursors-inspect:self:local) A body is not automatically a Self and does not gain authority merely by possessing bytes. ### 9. Receipts and the next cursor: close the loop Execution produces outputs and evidence. External effects should use stable idempotency/claim identifiers where possible and produce receipts that make retries and recovery explicit. Only after required outputs/evidence are available does the next signed cryptocursor become durable history. ```text old cryptocursor │ ├─ inputs ├─ carried authority ├─ execution / exchange └─ receipts ↓ new cryptocursor ``` That loop is the center of Cursors. Everything else can be replaced, optimized, or routed differently as long as observable semantics stay intact. ## The semantic planes The cockpit can show several planes at once. They are views over the same machine, not competing architectures. ### Object DAG: immutable material What stable content exists: programs, state/checkpoints, outputs, manifests, chunks, receipts and other independently addressable evidence. ### Cryptocursor DAG: durable causality + authority What executed, which records are parents, what may be resumed next, and how authority was attenuated/delegated/partitioned along that causal continuation. ### Curved dataspace: current coordination Attributed assertions and structural interests describing what is currently true or wanted from a particular projection. ### Fabric/exchange: movement and availability Addressed exchanges, live sessions, carriers, stores, mailboxes, reconciliation and recovery paths that move or make material available. These are operational mechanisms, not semantic identity/authority. One observation may appear in several views without the views becoming equivalent. ## Execution lifecycle A typical advancement is: 1. receive an interest, local program step, mailbox envelope, or open/wake request; 2. resolve immutable inputs; 3. verify cursor history and the authority lineage required for the proposed advancement/effect; 4. choose/restore a suitable execution body; 5. execute within explicit budgets; 6. persist outputs before publishing their references; 7. record external-effect receipts/evidence; 8. sign and publish the child cryptocursor. If the body disappears before publication, another body can resume from the previous durable cursor. If an external effect might already have escaped, the receipt protocol decides whether to observe, retry, compensate, or stop. Cursors hides placement aggressively; it does **not** hide uncertainty. ## Storage is machinery, not truth Different storage systems should keep different responsibilities: - live memory: current temporary body state; - SQLite/browser/local stores: reload-safe body operational state; - mailbox databases: operational addressed state; - immutable blocks: portable replication material; - analytical stores: derived views; - recovery carriers: additional availability paths. Persisting something does not make it authoritative or current. ## Host boundary and Metasocketry The semantic core should ask hosts for small explicit operations rather than importing a whole operating-system ontology: - open/inspect/release typed resources/handles; - wait for events/deadlines; - send and receive framed exchanges; - resolve and publish immutable material; - request signing/decryption without exporting secret keys; - execute isolated program steps; - observe device/external effects and return receipts. Linux, browsers, mobile systems, and embedded bodies can implement those operations differently. The companion `Spaceghost/metasocketry` project is intended to own **live virtual handle/socket/topology realization**. Its emerging high-level `open()` can yield a typed handle whose supported operations may include `read/write`, `send/recv`, `connect`, `listen/accept`, `poll`, or other explicit facets. A logical Metasocket may rebind across carriers when its declared semantics permit that. File descriptors, endpoint IDs, routes, and live sockets remain local operational machinery, not cursor identity or authority. This takes the useful pressure from BSD sockets and Plan 9/Inferno namespaces without pretending every resource is a byte-stream file. ## Cursor Machine placement The current executable scheduler puts SQLite inside a body, beneath durable Cursors semantics and above host storage. SQLite owns runnable selection, worker leases, authority admission, continuation state, Linda projections, checkpoints, outbox intents, receipts, and instrumentation. Restricted Lua supplies coarse program meaning and yields portable intents; it does not own transactions or receive a raw database handle. Nelua-generated Wasm is an optional authority-free packet accelerator, not a scheduler or authority source. Browser bodies keep the writable SQLite Wasm connection in one dedicated Worker. Native bodies use an owning thread or process, and mobile bodies use an app-owned background-capable task. Cloudflare Durable Object SQLite accepts verified bounded semantic records into its own schema; local database pages and WAL frames never cross this boundary. Cap'n Web and MessagePort pipelines reduce live round trips but are not durable continuation state. See [SQLite + Lua Cursor Machine](sqlite-lua-cursor-machine.md) and [the cockpit Machine Lab](cursor-machine-cockpit-lab.md). ## Logic placement Cursor Logic / Cryptolog should reason over explicit facts and horizons stored/projected through SQLite. The intended semantic center is bounded Datalog-style evaluation; Prolog/Trealla-like syntax/search can provide human-friendly goals, explanations, counterexamples and synthesis under budgets. Logic may derive facts such as: ```prolog candidate_resume(Cursor, Body). candidate_route(Target, Handle). openable(Cursor, Target, Profile). missing_receipt(Intent). ``` Those are proposals/explanations, not authority. A derived `openable` fact cannot create a socket, spend authority, or cause an effect. The explicit verifier + SQLite intent/outbox boundary remains between reasoning and reality. Distributed absence is not automatically false. Negative conclusions require an explicit closed-at-horizon/authority-complete basis; otherwise the answer is **unknown at this horizon**. ## Optimization rule Local implementations are allowed to cheat for speed as long as they do not cheat semantically. A local optimizer may replace an envelope with a function call, map an immutable object directly into memory, fuse several plan nodes, or keep a hot Metasocket handle. It may do so only when identity, cursor-carried authority, ordering, failure, uncertainty, and receipt behavior remain observationally equivalent. ## Learn the rest without loading it all For agents, use: ```sh npm run context -- "the task" ``` For the shortest human tutorial, continue with [Follow One Cursor](follow-a-cursor.md). For the live UI, continue with [Operations Console](operations-console.md). For programming, continue with [Cursor Apps and Contemporary Runtimes](cursor-apps.md).