# Mailboxes and traffic

Mailboxes are the addressed front door of the Cursors fabric. They hold deduplicated envelopes until an authorized receiver reads, acknowledges, relays, expires, or checkpoints them.

Chat is not a special subsystem. It is one message family beside cursor references, grants, assertions, interests, requests, replies, receipts, proposals, and signaling.

## What you are looking at

A mailbox should feel like a queue component with visible message structure, not a speech-bubble widget bolted onto the side of the system:

```text
sender / program / resolver
          │
          ▼
     envelope/v1
          │
          ▼
      [ MAILBOX ]
       │   │   │
       │   │   └── receipt / expiry
       │   └────── dedup / ordering
       └────────── addressed delivery
```

[Inspect LOCAL MAILBOX](#cursors-inspect:mailbox:local)

Select the wire connected to it as well. The wire should show the message family and representative fields rather than merely saying “traffic.”

## A rich envelope

A generic `envelope/v1` can expose:

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

Different envelope families specialize the payload without throwing away this common machinery.

## Envelope families

| Family | Carries | Durable by default? |
|---|---|---:|
| `chat/v1` | human or agent conversation with reply parents | local bounded log today |
| `cursor/v1` | cursor IDs, continuations, and checkpoint references | yes when accepted |
| `pointer/v1` | cryptopointers and resolver requests | policy-dependent |
| `dataspace/v1` | assertions, interests, facet and lease events | normally ephemeral |
| `capability/v1` | grant identifiers and presentations | records yes; secrets never |
| `receipt/v1` | delivery, resource, or external-effect evidence | yes |
| `signal/v1` | short-lived encrypted WebRTC candidates | no; short expiry |

The family should be visible on the wire and inspectable independently from its carrier.

## What delivery proves

Delivery and application effects have separate receipts.

```text
accepted by mailbox ≠ executed by body
transported by peer ≠ authored by peer
address known ≠ write authority
```

A locally signed envelope can provide author-key provenance. Capability references can provide authority evidence after verification. Those are explicit message fields, not properties inferred from the socket or peer that carried the bytes.

## What works now

Every inspectable cockpit level has a channel scoped to:

```text
site mount + curve address + inspected subject
```

Messages are stored as bounded local envelopes and synchronized across same-origin tabs with `BroadcastChannel`. When the local Self is unlocked, new messages are signed with that mailbox key and labelled `local-signed`; otherwise they remain explicitly unsigned. Both remain device-local unless another fabric is explicitly used.

Reloading preserves the bounded local log. The public deployment does not join a shared mailbox network or silently send drafts to a remote service.

## Message anatomy should stay visible

When inspecting a message, the UI should separate:

- **addressing:** where the envelope is intended to go;
- **causality:** reply/parent relationships;
- **author evidence:** signature/key evidence, or explicitly unproven;
- **authority:** capability references and decisions;
- **payload:** inline typed body or immutable pointer;
- **transport:** which wire/carrier moved it;
- **delivery:** dedup/receipt/expiry state;
- **execution:** if anything later consumed it and produced an effect receipt.

Those fields may be shown together because humans enjoy one screen, but they must not be semantically collapsed because computers enjoy incidents.

## Durable message choice

The recommended durable form is one signed cursor per durable message or batch, with explicit reply parents and a mailbox receipt. A locally signed envelope establishes key provenance but still needs an accepted durable checkpoint and delivery receipt before the cockpit calls it replicated.

Cheap local drafts may remain unsigned until an operator unlocks a Self or chooses to checkpoint.

## Storage tiers

1. **ephemeral UI** — unsaved typing and transient presence;
2. **local mailbox** — bounded reload-safe drafts on one origin/curve;
3. **explicit shared fabric** — a deliberately joined browser or other compatible fabric;
4. **meeting mailbox** — invitation-only shared curve;
5. **archival checkpoint** — signed cursor roots plus encrypted immutable bodies;
6. **optional remote mailbox** — separately deployed and explicitly admitted, never required by the browser-first core.

Moving outward is always explicit.

Continue with [Cryptofabrics](cryptofabrics.md), [Curve Spaces](curve-spaces.md), and [Capabilities](capabilities.md).