# Follow one cursor through the whole machine

This is the shortest technical path through Cursors.

Start with one piece of intent: **“play this media with my room, keep the coordination portable, and preserve what actually happened.”**

Do not start with transports. Do not start with keys. Follow the work in the order it moves through the system.

At every layer ask three questions:

1. **What is it?**
2. **What does it prove?**
3. **Where can I inspect it?**

```text
intent
  ↓
cryptopointer
  ↓
curve
  ↓
mailbox / exchange
  ↓
cryptofabric program
  ↓
cryptofabric carriers + stores
  ↓
body / exec
  ↓
cursor record + receipts
```

Authority is checked alongside this path. It is never inferred from transport membership.

## 1. Intent becomes an addressed request

The human intent first becomes something a Cursors body can name and coordinate.

A [Local Mailbox](#cursors-inspect:mailbox%3Alocal) can hold an addressed envelope for chat, a request, a pointer, an assertion, or another typed message.

### What does this prove?

Delivery proves only what the delivery evidence says. A received envelope is not automatically authenticated, authorized, or executed.

## 2. A cryptopointer says what should be resolved

The [Horizon Cryptopointer](#cursors-inspect:pointer%3Ahorizon) names a target plus a requested view and resolution constraints.

A cryptopointer may carry trust references, capability references, curve hints, locality preferences, and expiry information. It is deliberately richer than a raw URL and deliberately weaker than a bearer token.

### What does this prove?

By itself, usually very little. A pointer describes **what should be resolved and under what constraints**. Verification happens during resolution.

Read deeper: [Cryptopointers](cryptopointers.md).

## 3. The curve says whose projection we are using

The [Local Curve](#cursors-inspect:curve%3Alocal) represents the current body's relative projection of the world.

Different participants can legitimately see different projections because authority, locality, invitation scope, cost, and trust differ.

A future watch-party room can use a deliberately shared meeting curve while each participant still retains an independent identity and authority boundary.

### What does this prove?

A curve defines projection and scope. It does not prove participant identity merely because two things appear on the same curve.

Read deeper: [Curve Spaces](curve-spaces.md).

## 4. Mailbox and exchange move meaning

A mailbox accepts addressed, deduplicated envelopes. An **exchange** is meaningful material moving between Cursors machinery.

Examples include:

- chat and presence envelopes;
- media cryptopointers;
- cursor references;
- assertions and interests;
- requests and replies;
- capability references;
- effect and delivery receipts.

Select [LOCAL MAILBOX](#cursors-inspect:mailbox%3Alocal), then inspect its wire to the local fabric. The wire should explain the material it carries rather than merely existing as decoration.

### What does this prove?

Transport arrival does not prove authorship. Signed envelope material may provide stronger evidence when verified.

Read deeper: [Mailboxes and Traffic](mailboxes.md).

## 5. A cryptofabric program describes the work

Cursors programs should be inspectable **before** they execute.

The first plan operators are intentionally small:

```text
exchange(target)
mailbox(address)
exec(program)
split(...branches)
sequence(...steps)
```

For a browser watch party, a plan can say:

```text
sequence
  exchange(media pointer)
  split
    mailbox(room presence + chat)
    exec(playback synchronization)
```

The plan can expose where authority is required and which steps may cause effects before a body runs anything.

### What does this prove?

Nothing executes merely because a program description exists. **Planning is not authority.**

This layer can later grow operators such as `resolve`, `join`, `race`, `retry`, `assert`, `interest`, `store`, `checkpoint`, `delegate`, and `observe` without forcing those ideas into transport APIs.

Read deeper: [Cursor Apps and Contemporary Runtimes](cursor-apps.md).

## 6. Cryptofabric chooses carriers and stores

The [Browser Cryptofabric](#cursors-inspect:fabric%3Abrowser) and [Local Cryptofabric](#cursors-inspect:fabric%3Alocal) provide concrete paths underneath exchanges.

A browser body can use mechanisms such as:

- WebRTC / WebTorrent peer wires;
- HTTPS webseeds;
- BroadcastChannel for same-origin local exchange;
- browser persistence.

Other execution bodies may add TCP, µTP, UDP DHT, removable media, radio, or delay-tolerant stores later.

Select individual torrent sources, peers, HTTP seeds, fabrics, and the **wires themselves** in the cockpit. Zoom until their semantic strands are visible.

### What does this prove?

A carrier proves carrier facts only. A WebRTC connection proves that a session exists. A torrent peer proves that blocks can move. Neither fact establishes participant identity, decryption rights, cursor authorship, or execution authority.

Read deeper: [Cryptofabrics](cryptofabrics.md) and [Fallback Fabric](fallback-fabric.md).

## 7. Authority is checked separately

The [Capability Graph](#cursors-inspect:plane%3Aauthority) answers who may inspect, continue, delegate, persist, or cause effects.

A signed capability can bind a subject to a resource, exact rights, budgets, expiry, and delegation constraints. Attenuation may remove authority but must not manufacture additional authority.

### What does this prove?

A verified capability chain proves specific granted authority under its constraints. It says nothing about whether the subject happens to share a network path with us.

Read deeper: [Capabilities](capabilities.md).

## 8. A body executes

A **body** is the replaceable place where computation happens now: a browser tab, worker, native process, mobile app, VM, server, embedded device, or another compatible executor.

[SELF / BODY](#cursors-inspect:self%3Alocal) is deliberately separate from [BROWSER OBSERVER](#cursors-inspect:observer%3Abrowser). The execution body, identity, and transport observer are not the same concept.

Before an effect, a suitable body should:

1. resolve immutable inputs;
2. verify the relevant cursor history;
3. verify the required authority;
4. restore the continuation/checkpoint;
5. execute within explicit constraints;
6. persist outputs;
7. produce receipts for external effects.

### What does this prove?

Being capable of executing code does not grant permission to execute a particular step.

## 9. A new cursor preserves what happened

The [Cursor History](#cursors-inspect:plane%3Ahistory) is the durable result of the loop.

A new cursor may name:

- its parent cursor or parents;
- continuation/checkpoint references;
- immutable inputs and outputs;
- exercised capabilities;
- effect receipts;
- author and execution-body hints;
- logical time.

The old cursor is never edited. Forking creates children. Joining names multiple parents.

```text
old cursor
   │
   ├─ resolved inputs
   ├─ exercised capabilities
   ├─ execution / exchange
   └─ effect receipts
          ↓
      new cursor
```

The transports may disappear. The browser tab may close. The executing machine may vanish. The portable history remains independently meaningful if its referenced evidence can still be recovered and verified.

Read deeper: [Cursor Records](crypto-cursors.md).

## The separation to remember

| Thing | Main question | Does not automatically prove |
| --- | --- | --- |
| Cursor | What happened and what can continue? | Authority to continue |
| Cryptopointer | What should be resolved? | Permission to use it |
| Curve | From whose projected context? | Participant identity |
| Mailbox | Where do addressed envelopes go? | Envelope authorship |
| Program | What work is proposed? | Permission to execute it |
| Cryptofabric | How can material move or persist? | Identity or authority |
| Body | Where can code execute? | Permission to cause effects |
| Capability | Who may do exactly what? | Network reachability |
| Receipt | What evidence came back from an effect? | All surrounding intent |

If the cockpit ever visually contradicts these separations, treat that as a UI bug.

## Continue from here

For the conceptual map, read [Architecture](architecture.md).

For the live instrument, read [Operations Console](operations-console.md).

For programming, continue with [Cursor Apps and Contemporary Runtimes](cursor-apps.md).

For a non-technical introduction, use [First Flight for Everyone](first-flight-for-everyone.md).