# Cryptopointers

A **cryptopointer** is a portable, inspectable request to resolve something. It says what should be followed, what view is wanted, and which constraints must shape resolution.

It is not a raw address, capability, bearer token, private key, live socket, or promise that the target is available.

## What you are looking at

In the cockpit, a pointer should look like a small resolver component with clearly separated pins:

```text
 target ─────┐
 view ───────┼──▶ [ CRYPTOPOINTER ] ───▶ resolver plan
 trust refs ─┤
 grants refs ┤
 curve hint ─┤
 locality ───┤
 expiry ─────┘
```

[Inspect HORIZON CRYPTOPOINTER](#cursors-inspect:pointer:horizon)

The wires around it are not generic lines. A resolution wire carries a `resolve/v1` message family with fields such as target, requested view, resolver constraints, trust references, capability references, curve hint, locality preference, and expiry.

## Pointer shape

| Field | Meaning |
|---|---|
| target | immutable object, cursor, mailbox, world, or named resolver target |
| view | bytes, typed object, stream, mapping, continuation, mailbox head, or another requested projection |
| trust | accepted key or release fingerprints; never private keys |
| grants | capability identifiers presented separately during resolution |
| curve | authority-relative projection and relationship hints |
| locality | optional same-body, LAN, preferred fabric, cost, or latency hints |
| expiry | when mutable resolution hints must no longer be used |

Knowing a pointer grants nothing. The resolver may return data, a mapping, a computation plan, another pointer, a structured denial, or an explicit unavailable result.

## Natural mental model

Think of the pointer as an **inspectably constrained dereference request**:

```text
pointer
  │
  ├─ what?        target
  ├─ as what?     requested view
  ├─ under what?  trust / grants / curve / locality / expiry
  ▼
resolver
  ▼
value | mapping | fetch | computation | redirect | denial | unavailable
```

The important separation is:

```text
reference ≠ authority
```

A pointer can mention capability identifiers, but the authority must still be independently presented and verified.

## Three pointers visible in the cockpit

### Horizon pointer

Names the selected frontier of cursor history. Following it asks which immutable cursor roots this view currently considers live or relevant.

### Mailbox pointer

Names one mailbox relative to a curve. The mailbox address locates an envelope queue; separate identity and capability decisions decide who may read, append, relay, or administer it.

### Object pointer

Names immutable content and a requested representation. A compatible resolver may map it locally, fetch it from a webseed or swarm, compute it, or deny it.

## What a resolution wire can prove

A successful resolution may prove that a particular resolver verified a target and produced a stated result under stated constraints. It does not automatically prove:

- that the requester was authorized unless capability verification is included;
- that a returned carrier peer is an identity;
- that a fetched object may be executed;
- that a local mapping should be persisted.

## Local and network cost

A cheap local pointer may contain only a local object identifier and `curve:local` hint. It can still produce the same semantic result shape as a network pointer. Cryptography is added when a boundary needs independent provenance, not because every local reference should be expensive.

## Pointer invariant

```text
cryptopointer + requested operation + presented authority + observer locality
    → verified resolver plan
    → value | mapping | fetch | computation | redirect | denial | unavailable
```

The pointer remains portable because POSIX paths, file descriptors, JavaScript objects, and memory addresses stay inside resolver adapters.

Continue with [Curve Spaces](curve-spaces.md), [Mailboxes and Traffic](mailboxes.md), and [Cryptofabrics](cryptofabrics.md).