# Cryptofabrics

A **cryptofabric** is the machinery that moves and stores Cursors material without pretending the machinery itself is identity or authority.

The cockpit should make a fabric feel like a board you can probe:

```text
producer / mailbox / resolver
          │
          ▼
   semantic envelope
          │
    ┌─────┴─────┐
    │ fabric bus │
    └─────┬─────┘
          │
   carrier / store
          │
          ▼
consumer / mailbox / body
```

## What you are looking at

When you select a **fabric node**, you are looking at an ensemble of routing, admission, deduplication, persistence, rendezvous, and carrier choices.

When you select a **wire**, you are looking at one relationship inside that ensemble.

When you zoom into a wire, the little packets are **message specimens**: structured examples of the semantic material that can ride that relationship. They are not meant to imply that every modeled field is presently observed on the network.

[Inspect BROWSER CRYPTOFABRIC](#cursors-inspect:fabric:browser)

[Inspect LOCAL CRYPTOFABRIC](#cursors-inspect:fabric:local)

## A wire is richer than bytes

The lower carrier may only know about frames and bytes, but Cursors needs the higher semantic envelope to remain inspectable.

A mailbox wire can carry something shaped like:

```text
envelope/v1
  id
  subject
  causal parents[]
  author evidence
  capability refs[]
  payload ref/body
  expiry
  receipt policy
```

A pointer-resolution wire can carry:

```text
resolve/v1
  target
  requested view
  resolver constraints
  trust refs[]
  capability refs[]
  curve hint
  locality preference
  expiry
```

An authority-bearing wire is visibly different:

```text
grant/v1
  issuer fingerprint
  subject
  resource
  rights[]
  budgets
  validity
  nonce
  signature
```

Only the last family may carry explicit authority after verification. The TCP, WebRTC, torrent, HTTP, relay, or local-memory carrier underneath it still grants nothing by itself.

## Carriers are replaceable machinery

A browser body can use:

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

Other bodies may use TCP, µTP, UDP DHT, IPC, removable media, radio, or delay-tolerant stores.

The message model should not have to mutate every time the carrier changes.

## What each visible layer proves

| Visible thing | Useful evidence | Does not automatically prove |
| --- | --- | --- |
| semantic message | declared fields, signatures/refs when present | successful delivery or execution |
| wire | relationship and observation state | identity or authority |
| carrier frame | bytes moved on a transport | message authorship |
| piece hash | immutable-piece integrity | decryption right |
| delivery receipt | the stated delivery fact | external effect completion |
| capability/grant | explicit rights after verification | reachability |

## Natural inspection rule

The user should be able to move in either direction:

```text
message → wire → fabric → carrier
```

or:

```text
carrier → wire → message family → authority / identity evidence
```

without the UI silently changing what kind of fact is being inspected.

That is why transport, message, identity, authority, execution, and persistence stay visually distinct even when they overlap on the same physical path.

## Programming a fabric

Cryptofabric programs describe meaningful work before execution:

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

A program can therefore be rendered as machinery before a body runs it. Future operators such as `resolve`, `join`, `race`, `retry`, `store`, `checkpoint`, `delegate`, and `observe` should preserve the same inspectability.

Continue with [Mailboxes and Traffic](mailboxes.md), [Cryptopointers](cryptopointers.md), and [Cursor Apps and Contemporary Runtimes](cursor-apps.md).