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:
- What is it?
- What does it prove?
- Where can I inspect it?
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 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 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.
3. The curve says whose projection we are using
The Local Curve 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.
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, 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.
5. A cryptofabric program describes the work
Cursors programs should be inspectable before they execute.
The first plan operators are intentionally small:
exchange(target)
mailbox(address)
exec(program)
split(...branches)
sequence(...steps)
For a browser watch party, a plan can say:
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.
6. Cryptofabric chooses carriers and stores
The Browser Cryptofabric and Local Cryptofabric 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 and Fallback Fabric.
7. Authority is checked separately
The Capability Graph 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.
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 is deliberately separate from BROWSER OBSERVER. The execution body, identity, and transport observer are not the same concept.
Before an effect, a suitable body should:
- resolve immutable inputs;
- verify the relevant cursor history;
- verify the required authority;
- restore the continuation/checkpoint;
- execute within explicit constraints;
- persist outputs;
- 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 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.
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.
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.
For the live instrument, read Operations Console.
For programming, continue with Cursor Apps and Contemporary Runtimes.
For a non-technical introduction, use First Flight for Everyone.